|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Perry Merritt (perry, merrittclan dot com) Date: 2001.09.28 - 09.47 MDT
X-Mailer: Visto Server Unless of course the user tries to start reading random locations in the file. If you extend your idea to try to have partial video streams on disk and backfill them from tape, it seems like a plausible idea. It would also mean we'd have to keep track of how much is actually written to disk at any point in time. -----Original Message----- From: Don jessup djessup72, yahoo dot com Sent: Fri, 28 Sep 2001 08:25:54 -0700 (PDT) To: antera, cryptofreak dot org Subject: Re: Meeting thoughts and some other stuff. Here is another reason I like going thru the portal on restore. We could unblock the open almost immediatly and stream the data to disk and to the user at the same time. Here are those documents again. --- Perry and Lorae Merritt <plmerritt, hypermall dot net> wrote: > For ADC security, can't we just validate that the > UID asking about a file or > trying to modify a file has permission to the file? > Essentially we'd just > tie into the OS/file system security that already > exists (UID/GID). > > ----- Original Message ----- > From: "Jay Miller" <jnmiller, cryptofreak dot org> > To: <antera, cryptofreak dot org> > Sent: Thursday, September 27, 2001 9:28 PM > Subject: Re: Meeting thoughts and some other stuff. > > > > - Words by Perry and Lorae Merritt > <plmerritt, hypermall dot net> [010927 > 05:19]: > > > Don't start with me? I never planned to stop > with you. > > > > Careful - I'll tell my girlfriend to stop talking > to you! (I bought her > > a laptop.. what did YOU buy her? :) > > > > > During the meeting you can tell me again(?) how > you plan on moving the > data > > > from the restore operation through the ADML to > the fileystem. Are you > > > thinking you're going to send it through the > portal/ioclt interface? If > so, > > > how are you going to get it from the restore > that is doing file writes? > > > > Pipes, I suppose. Instead of writing to a normal > file descriptor, we > > write to stdin and parse the incoming stream for > the raw data. We might > > also be able to do some verification on file > metadata to make sure the > > two copies (one of which should be of zero-size) > are of one another. > > Anyway, once we know what the raw data is (we > don't really need the > > metadata), we cram it through the portal to the > kernel and do standard > > write() calls. > > > > Sounds pretty clean..? > > > > > It seems to me that if we don't expose our > internal mechanism for > figuring > > > out who's doing the open and subsequent writes, > the opportunity for > someone > > > wanting to break our system should be fairly > narrow. In fact, whats to > stop > > > them from writting their own ADC and doing > whatever they want as it is? > > > > Security through of obscurity? Perry, you should > know better than to > > propose a scheme like that to me! > > > > (http://www.loktechnology.com/encryption.html) > > > > The nice thing about communication with the ADML > being kept to only > > pieces we write is the ability to have both sides > manage the > > 'connection'. We are able to negotiate security > protocols this way. > > Giving messages to our kernel module 'from the > top', as it were, makes > > it much harder to know who's talking to us. > > > > Your point about rogue ADC's is actually a very > good one to bring up and > > keep in mind. The idea that this software setup > could be running on > > some companies' "master server" implies that > hostile actions might be > > attempted against our stuff. Access to the ADML, > after all, entails > > access to anything in the system, including all > file data. Any actual > > product should probably account for this. Dan, > you might wish to think > > about this from a sales perspective, too: we're > essentially making a back > > door into the kernel - something many admins might > be hesitant about..? > > > > Right. > > > > Now, here's the interesting and (I thought) > radical idea we came across > > today: no PD. We've mentioned a lot that the ADML > layer is just a > > flexible way to implement extended attributes > (EAs). And we're planning > > on never actually deleting the file itself from > the FS - just the > > metadata. So why not utilize that data structure > to store our own data? > > > > The PDM would still be responsible for managing > that stuff, and we might > > need to manage some kind of hash or some other > quick structure for > > searching the EAs (for high UEFs, or whatever..). > > > > Neat idea? > > > > I love simplifying things.. > > > > -- > > Jay Miller > > > > ICQ: 32123421 | YM: ladenedge | > http://www.cryptofreak.org > > PGP: 0xedc9bb8d | 41a6428c 46abd36b 6b259b68 > 8a28ca4c edc9bb8c > > -- > > This is the antera mailing list. To unsubscribe, > email > > majordomo, cryptofreak dot org with message body > `unsubscribe antera'. > > Or, for more information, visit > http://www.cryptofreak.org/. > > > > -- > This is the antera mailing list. To unsubscribe, > email > majordomo, cryptofreak dot org with message body > `unsubscribe antera'. > Or, for more information, visit http://www.cryptofreak.org/. __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com ___________________________________________________________________________ Visit http://www.visto.com. Find out how companies are linking mobile users to the enterprise with Visto. -- This is the antera mailing list. To unsubscribe, email majordomo, cryptofreak dot org with message body `unsubscribe antera'. Or, for more information, visit http://www.cryptofreak.org/.
This archive was generated by hypermail 2b30 : 2001.09.29 - 03.00 MDT |
