On 2017-09-15 15:41, Ulli Horlacher wrote:
On Fri 2017-09-15 (13:16), Austin S. Hemmelgarn wrote:
And then mount enryptfs:
mount.ecryptfs /<MOUNTPOINT_ENCRYPTED> /<MOUNTPOINT_DECRYPTED>
This only possible by root.
For a user it is not possible to have access for his own snapshots.
Bad.
Which is why you use EncFS (which is a FUSE module that runs in
userspace and requires no root privileges) instead of eCryptFS (which is
a kernel assisted filesystem that doesn't use FUSE, has more complicated
setup constraints, and requires CAP_SYS_ADMIN or root access).
I use both, encfs and ecryptfs, for different use cases.
I use ecryptfs on my notebooks for $HOME, which has some kind of
automounter on login (via pam).
This setup is not possible with encfs, which is also much slower and has
a lower security level.
Actually it is, it's just not trivially easy like with eCryptFS. the
pam_script module can be used to perform auto-mounting on login as well.
But even for encfs it is very circumstantial for a user to have access to
snapshots.
It's still a case where it's a problem of the combined usage of the two,
and it's not likely to get fixed by either. In theory, it should be
possible to have some hook added that handles mounting the snapshots
when one is taken and when the user logs in, but that isn't the job of
BTRFS at all (filesystems are supposed to not care about what's using
them), and I don't see it as likely that EncFS or eCryptFS will add
support either (they can't reliably watch for snapshot creation, so they
would have to add snapshot support and force you to go through them).
Overall, you're likely to be better off arguing for BTRFS native support
for the VFS encryption API (that is, F2FS and ext4 style native per-file
encryption).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
