* Joe Pfeiffer <[EMAIL PROTECTED]> [070321 20:58]: > Tim Newsom writes: > > > >On Wed, 21 Mar 2007 9:34, Joe Pfeiffer wrote: > >> Tobias Gruetzmacher writes: > >> > >> Right -- these look like good approaches, but to a different problem. > > > >/please excuse my direct manner.. Its just how I write (smile) > > Likewise -- it's hard to see somebody smile by email, and I never > intend to offend. > > >What do you mean by different problem? Maybe I don't fully > >understand. > > Near as I can tell, these approaches require you to partition up your > maching into an unencrypted area and an encrypted jail -- maybe > through a physically separate device, maybe through a separate > partition, maybe through a file that's mounted as a filesystem. I > don't want that -- I want to be able to specify encryption on a > file-by-file basis, in a manner that comes as close as possible to > being generic across all applications without code changes to those > applications. > > At the moment, I'm wandering around the source code for __libc_read() and > __libc_write() to see if there's a good way to hijack a program's > read() and write() calls, so if they are to a file that's marked as > encrypted the data can go through encrypt() on the way....
Yes, you can in theory do that. E.g. use a LD_PRELOAD library. BUT, here come the pitfalls: a) you need to keep extreme exact file positions. Or use lseek on every read/write to get your place in the file. b) mmap. c) from my experience, stdio.h, C++ streams and unistd.h read/write reach a different site for the kernel syscall. That might have changed or have been an artifact of LD_PRELOADing into the app. So encryptfs sounds way more useful for that usage. Andreas _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
