|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Perry and Lorae Merritt (plmerritt, hypermall dot net) Date: 2001.09.28 - 06.15 MDT
X-Mailer: Microsoft Outlook Express 5.50.4522.1200 My comments/questions are down towards the bottom. For those of you that can handle html you'll see them in bold italics. Hope we're meeting today. Can someone give me a call if we're not? Otherwise I'll plan on the library at 11:30. P ----- 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) > It would be nice if your links were actual links, instead of plain text that we have to cut and paste into our browsers. ;-) > 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..? > He's just going to ask us to solve it. > 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? > Um... We're definitely deleting the file, how else are you going to reclaim the space? If you're back on the idea of leaving the metadata (and that's what you really meant) how have you solved the problem of keeping track of the file name? Where are you going to store our info when the file is on disk? Are you counting on the file systems below us to provide us with space in their data structures? Are you planning on developing knowledge of the internal data structures inside each file system? > 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.. > I just wished the ideas worked. ;-) > -- > 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/.
This archive was generated by hypermail 2b30 : 2001.09.29 - 03.00 MDT |
