Re: snapshots of encrypted directories?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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).