|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Jay Miller (jnmiller, cryptofreak dot org) Date: 2001.09.27 - 21.28 MDT
X-Mailer: Mutt 1.2.5i - 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 archive was generated by hypermail 2b30 : 2001.09.28 - 03.00 MDT |
