On 21 April 2011 13:31, Darren J Moffat <darr...@opensolaris.org> wrote:
>> Now I get a problem. I was expecting to have to enter the pass >> phrase again when attempting to mount the file system, but this is not >> being >> requested. As you can see, I can mount the file system without the pass >> phrase and read the data on the file system. > > I covered that in the talk last night - in fact we had about a 5 minute > discussion about why it is this way. > > If you want the key to go away you need to run: > > # zfs key -u rpool/export/home/davek > >> drkirkby@laptop:~# zfs mount rpool/export/home/davek >> drkirkby@laptop:~# ls /export/home/davek/foo >> /export/home/davek/foo >> drkirkby@laptop:~# >> >> This looks wrong to me, but I've no idea how to solve it. > > No it is correct by design. > > As I mentioned last night the reason for this is so that delegated > administration of certain properties can work for users that don't have the > 'key' delegation and don't have access to the wrapping keys. > > For example changing a mountpoint causes an umount followed by a mount. > There are other changes that under the covers can cause a filesystem to be > temporarily unmounted and remounted. Thanks. You did loose me in some places - I guess that was one of them. >> The next issue is how do I get the file system to mount when the > >> machine is booted? I want to supply the pass phrase by typing it in, >> rather than from storing it in USB stick or other similar method. > > Since this is your user home directory the ideal way would be a PAM module > that ran during user login and requested the passphrase for the ZFS > encrypted home dir. > > There isn't one in Solaris 11 Express (snv_151a) at this time. > >> Any ideas what I need to do to get this file system to request the >> pass phrase before mountin g the file system? > > There is source for a prototype PAM module in the old opensolaris.org > zfs-crypto repository: > > http://src.opensolaris.org/source/history/zfs-crypto/phase2/usr/src/lib/pam_modules/ > > You would need to take a clone of that repository and check out changeset > 6749:6dded109490e and see if that old PAM module could be hacked into > submission. Note that it uses private interfaces and doing so is not > supported by any Oracle support contract you have. > > -- > Darren J Moffat I don't fancy going to that length. Are there simpler options, that don't require hacking the system so much? I guess one way is to store very little in one's home directory, then store all potentially sensitive data in another file system. I'm not overly concerned about what might be in $HOME/.bash_history or similar. Dave _______________________________________________ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
