few kinks and one question. a. what is svnd? (srry :x)
2. what fs is mountable and dynamic in size? your suggesting mounting each seperate users home on login, though this would (based on all of my knowledge of current filesystems) that it would have to be of a static size. for quotas this would be fine, but id imagine a lot of people wont like this. c. your going to make a passwd change transparent as well? not many do, but i for one do change my password every 90 days, and having the key for my home re-keyed/re-encrypted im not going to remember. 4. must ensure not to umount if im still logged in? BUT i for one do not want my home to remain mounted if someone has su'd as me. and how will this work if someone sets utmp/wtmp o-rwx. ... i disavowed any questions of root access, as per the theory of; if homes are encrypted, root should not require access to homes, and thus will never be used on *public* boxes (shell companies in particular) BUT i will say this is a fantastic idea. ive done partition encryption on linux but that just saves you from someone cd'ing your box. protecting each user would wrock!!! oh, where is the code you have 'now' that you said? id really like to view . - Zac On Thu, 1 Dec 2005 01:48:12 +0100 (CET), [EMAIL PROTECTED] wrote: > Hi guys, > > I thought about a way of de-/encrypting home-directories transparently to > users. I've got a vague idea how to realize this in a reasonable way: > > * Generate a key, associate it with a new svnd-image, prepare the image > * Encrypt the key with the users login password, store it in /home > * On login, decrypt the key with the password > * Pass the decrypted key to vnconfig and mount the image on $HOME > > This has some consequences, like > - creating a new login facility login_decrypt (or sth. similar) > - writing a program for keyfile/image generation and password changing > - modify vnconfig to read keys from other sources than stdin > > Since I already got some code, it might be smart to ask now for some > feedback before heading into a completely wrong direction. > There are probably better ways to accomplish this, so generally opinions > regarding the issue would be cool. > > All the best, > /Markus
