Code review comment for lp:~rlaager/ecryptfs/fix-lp-1574174-2

Richard Laager (rlaager) wrote :

Bottom line: I haven't run into any problems in my testing, but I'm not personally running it day-to-day.

It's something I've long supported in my HOWTO for root-on-ZFS, but I don't know how many people use that combination. I primarily support it because it's supported out-of-the-box (i.e. in the installer) by Ubuntu on non-ZFS filesystems.

I filed this bug report because if I'm going to support it, it'd be nice if it didn't need the extra steps: "create the ZFS filesystem at /home/temp-USER, ecryptfs-setup-private, rename the temp-USER filesystem to USER".

Coincidentally, I've just posted something to the ZFS-on-Linux mailing list which may elicit responses from such users (among others).

The reason I personally stopped using ecryptfs (which I used for years, first for ~/Private, then ~) when I moved to ZFS is that I lose the ability to dive into old snapshots easily. In ZFS, you can do this with "cd ~/.zfs/snapshot". The problem is that the children of .zfs/snapshot are auto-mounted. And my skills were not enough to figure out any way to make ecryptfs work through that auto-mount transparently. I'm not a kernel guy, but I did dive into the kernel code a bit.

So with the current state of affairs, I'd have to dig up the ecryptfs private key and mount the snapshot somewhere else through ecryptfs to be able to read my data.

People seem to be more interested in running LUKS under ZFS. This provides all the goodness of ZFS, with the encryption they want.

« Back to merge proposal