snapshots of encrypted directories?

snapshots of encrypted directories?

[Ulli Horlacher]

I use encfs on top of btrfs.
I can create btrfs snapshots, but I have no suggestive access to the files
in these snaspshots, because they look like:

drwx------  framstag users        - 2017-09-08 11:47:18 uHjprldmxo3-nSfLmcH54HMW
drwxr-xr-x  framstag users        - 2017-09-08 11:47:18 wNEWaDCgyXTj0d-Myk8wXZfh
-rw-r--r--  framstag users      377 2015-06-12 14:02:53 -zDmc7xfobKDkbl8z7oKOHxv
-rw-r--r--  framstag users    2,367 2012-07-10 14:32:30 7pfKs27K9k5zANE4WOQEuFa2
-rw-------  framstag users      692 2009-10-20 13:45:41 8SQElYCph85kDdcFasUHybVr
-rw-------  framstag users    2,872 2017-08-31 16:21:52 bm,yNi1e4fsAClDv7lNxxSfJ
lrwxrwxrwx  framstag users        - 2017-06-01 15:53:00 GZxNYI0Gy96R18fz40f7k5rl -> wvuQKHYzdFbar18fW6jjOerXk2IsS4OAA2fnHalBZjMQ,7Kw0j-zE3IJqxhmmGBN8G9
-rw-r--r--  framstag users      182 2016-12-01 13:34:31 rqtNBbiYDym0hPMbBL-VLJZcFZu6nkNxlsjTX-sU88I4I1

I have to mount the snapshot with encfs, to have access to the (decrypted)
files. 

Any better ideas?

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<20170914145739.GA32347@rus.uni-stuttgart.de>

Re: snapshots of encrypted directories?

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Thu, Sep 14, 2017 at 04:57:39PM +0200, Ulli Horlacher wrote:
> I use encfs on top of btrfs.
> I can create btrfs snapshots, but I have no suggestive access to the files
> in these snaspshots, because they look like:
> 
> drwx------  framstag users        - 2017-09-08 11:47:18 uHjprldmxo3-nSfLmcH54HMW
> drwxr-xr-x  framstag users        - 2017-09-08 11:47:18 wNEWaDCgyXTj0d-Myk8wXZfh
> -rw-r--r--  framstag users      377 2015-06-12 14:02:53 -zDmc7xfobKDkbl8z7oKOHxv
> -rw-r--r--  framstag users    2,367 2012-07-10 14:32:30 7pfKs27K9k5zANE4WOQEuFa2
> -rw-------  framstag users      692 2009-10-20 13:45:41 8SQElYCph85kDdcFasUHybVr
> -rw-------  framstag users    2,872 2017-08-31 16:21:52 bm,yNi1e4fsAClDv7lNxxSfJ
> lrwxrwxrwx  framstag users        - 2017-06-01 15:53:00 GZxNYI0Gy96R18fz40f7k5rl -> wvuQKHYzdFbar18fW6jjOerXk2IsS4OAA2fnHalBZjMQ,7Kw0j-zE3IJqxhmmGBN8G9
> -rw-r--r--  framstag users      182 2016-12-01 13:34:31 rqtNBbiYDym0hPMbBL-VLJZcFZu6nkNxlsjTX-sU88I4I1
> 
> I have to mount the snapshot with encfs, to have access to the (decrypted)
> files. 
> 
> Any better ideas?

   I'd say it's doing exactly what it should be doing. You're making a
copy of an encrypted data store, and the result is encrypted. In order
to read it, it needs to have the decrpytion layer applied to it with
the correct key (which is the need to mount the snapshot with encfs).

   Would you _really_ want a system where the encrypted contents of a
subvolume can be decrypted by simply snapshotting it?

   Hugo.

-- 
Hugo Mills             | Great films about cricket: Umpire of the Rising Sun
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: snapshots of encrypted directories?

[Andrei Borzenkov]

[-- Attachment #1.1: Type: text/plain, Size: 1983 bytes --]

14.09.2017 18:32, Hugo Mills пишет:
> On Thu, Sep 14, 2017 at 04:57:39PM +0200, Ulli Horlacher wrote:
>> I use encfs on top of btrfs.
>> I can create btrfs snapshots, but I have no suggestive access to the files
>> in these snaspshots, because they look like:
>>
>> drwx------  framstag users        - 2017-09-08 11:47:18 uHjprldmxo3-nSfLmcH54HMW
>> drwxr-xr-x  framstag users        - 2017-09-08 11:47:18 wNEWaDCgyXTj0d-Myk8wXZfh
>> -rw-r--r--  framstag users      377 2015-06-12 14:02:53 -zDmc7xfobKDkbl8z7oKOHxv
>> -rw-r--r--  framstag users    2,367 2012-07-10 14:32:30 7pfKs27K9k5zANE4WOQEuFa2
>> -rw-------  framstag users      692 2009-10-20 13:45:41 8SQElYCph85kDdcFasUHybVr
>> -rw-------  framstag users    2,872 2017-08-31 16:21:52 bm,yNi1e4fsAClDv7lNxxSfJ
>> lrwxrwxrwx  framstag users        - 2017-06-01 15:53:00 GZxNYI0Gy96R18fz40f7k5rl -> wvuQKHYzdFbar18fW6jjOerXk2IsS4OAA2fnHalBZjMQ,7Kw0j-zE3IJqxhmmGBN8G9
>> -rw-r--r--  framstag users      182 2016-12-01 13:34:31 rqtNBbiYDym0hPMbBL-VLJZcFZu6nkNxlsjTX-sU88I4I1
>>
>> I have to mount the snapshot with encfs, to have access to the (decrypted)
>> files. 
>>
>> Any better ideas?
> 
>    I'd say it's doing exactly what it should be doing. You're making a
> copy of an encrypted data store,

With all respect - snapshot is not a copy.

> and the result is encrypted. In order
> to read it, it needs to have the decrpytion layer applied to it with
> the correct key (which is the need to mount the snapshot with encfs).
> 

But snapshot *is* mounted implicitly as it is part of mounted btrfs
filesystem. So I can see that this behavior could be rather unexpected.

>    Would you _really_ want a system where the encrypted contents of a
> subvolume can be decrypted by simply snapshotting it?

The actual question is - do you need to mount each individual btrfs
subvolume when using encfs? If yes, this behavior is at least
consistent. If not - how are snapshots different?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: snapshots of encrypted directories?

[Ulli Horlacher]

On Fri 2017-09-15 (06:45), Andrei Borzenkov wrote:

> The actual question is - do you need to mount each individual btrfs
> subvolume when using encfs? 

And even worse it goes with ecryptfs: I do not know at all how to mount a
snapshot, so that the user has access to it.

It seems snapshots are incompatible with encrypted filesystems :-(


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<ac97097d-f107-042c-f402-580a2ab5aa76@gmail.com>

Re: snapshots of encrypted directories?

[Peter Becker]

2017-09-15 12:01 GMT+02:00 Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
> On Fri 2017-09-15 (06:45), Andrei Borzenkov wrote:
>
>> The actual question is - do you need to mount each individual btrfs
>> subvolume when using encfs?
>
> And even worse it goes with ecryptfs: I do not know at all how to mount a
> snapshot, so that the user has access to it.

A snapshot is simply a subvolume.

Get the ID of the snapshot and mount it:

btrfs subvolume list /btrfs
mount -o subvolid=<ID> /dev/<DISK> /<MOUNTPOINT_ENCRYPTED>

Or mount the snapshot directly by path:

mount -o subvol=/snapshots/home/2015-12-01 /<MOUNTPOINT_ENCRYPTED>

And then mount enryptfs:

mount.ecryptfs /<MOUNTPOINT_ENCRYPTED> /<MOUNTPOINT_DECRYPTED>

Re: snapshots of encrypted directories?

[Ulli Horlacher]

On Fri 2017-09-15 (12:15), Peter Becker wrote:
> 2017-09-15 12:01 GMT+02:00 Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
> 
> > On Fri 2017-09-15 (06:45), Andrei Borzenkov wrote:
> >
> >> The actual question is - do you need to mount each individual btrfs
> >> subvolume when using encfs?
> >
> > And even worse it goes with ecryptfs: I do not know at all how to mount a
> > snapshot, so that the user has access to it.
> 
> A snapshot is simply a subvolume.
> 
> Get the ID of the snapshot and mount it:
> 
> btrfs subvolume list /btrfs
> mount -o subvolid=<ID> /dev/<DISK> /<MOUNTPOINT_ENCRYPTED>
> 
> Or mount the snapshot directly by path:
> 
> mount -o subvol=/snapshots/home/2015-12-01 /<MOUNTPOINT_ENCRYPTED>
> 
> 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.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<CAEtw4r1KUQJGZkKEA+e3J=3+4a9hW+-ZBRBfTXhwYn4Ae30CCw@mail.gmail.com>

Re: snapshots of encrypted directories?

[Austin S. Hemmelgarn]

On 2017-09-15 12:28, Ulli Horlacher wrote:
> On Fri 2017-09-15 (12:15), Peter Becker wrote:
>> 2017-09-15 12:01 GMT+02:00 Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
>>
>>> On Fri 2017-09-15 (06:45), Andrei Borzenkov wrote:
>>>
>>>> The actual question is - do you need to mount each individual btrfs
>>>> subvolume when using encfs?
>>>
>>> And even worse it goes with ecryptfs: I do not know at all how to mount a
>>> snapshot, so that the user has access to it.
>>
>> A snapshot is simply a subvolume.
>>
>> Get the ID of the snapshot and mount it:
>>
>> btrfs subvolume list /btrfs
>> mount -o subvolid=<ID> /dev/<DISK> /<MOUNTPOINT_ENCRYPTED>
>>
>> Or mount the snapshot directly by path:
>>
>> mount -o subvol=/snapshots/home/2015-12-01 /<MOUNTPOINT_ENCRYPTED>
>>
>> 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).

Re: snapshots of encrypted directories?

[Ulli Horlacher]

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.

But even for encfs it is very circumstantial for a user to have access to
snapshots.

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<6cd1ef22-7cab-4c8c-0b73-d254aeca83ad@gmail.com>

Re: snapshots of encrypted directories?

[Austin S. Hemmelgarn]

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

Re: snapshots of encrypted directories?

[Dave]

On Fri, Sep 15, 2017 at 6:01 AM, Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
>
> On Fri 2017-09-15 (06:45), Andrei Borzenkov wrote:
>
> > The actual question is - do you need to mount each individual btrfs
> > subvolume when using encfs?
>
> And even worse it goes with ecryptfs: I do not know at all how to mount a
> snapshot, so that the user has access to it.
>
> It seems snapshots are incompatible with encrypted filesystems :-(


My experience is the opposite. I use dm-crypt as well as encfs with
BTRFS and everything, including snapshots, works as I would expect it
to work.

I have been able to successfully restore snapshots that contained
encrypted data.

I think the other answers have already provided more details than I
could provide, so I just wanted to add the fact that my experience has
been positive with BTRFS snapshots and encryption.

Re: snapshots of encrypted directories?

[Austin S. Hemmelgarn]

On 2017-09-14 23:45, Andrei Borzenkov wrote:
> 14.09.2017 18:32, Hugo Mills пишет:
>> On Thu, Sep 14, 2017 at 04:57:39PM +0200, Ulli Horlacher wrote:
>>> I use encfs on top of btrfs.
>>> I can create btrfs snapshots, but I have no suggestive access to the files
>>> in these snaspshots, because they look like:
>>>
>>> drwx------  framstag users        - 2017-09-08 11:47:18 uHjprldmxo3-nSfLmcH54HMW
>>> drwxr-xr-x  framstag users        - 2017-09-08 11:47:18 wNEWaDCgyXTj0d-Myk8wXZfh
>>> -rw-r--r--  framstag users      377 2015-06-12 14:02:53 -zDmc7xfobKDkbl8z7oKOHxv
>>> -rw-r--r--  framstag users    2,367 2012-07-10 14:32:30 7pfKs27K9k5zANE4WOQEuFa2
>>> -rw-------  framstag users      692 2009-10-20 13:45:41 8SQElYCph85kDdcFasUHybVr
>>> -rw-------  framstag users    2,872 2017-08-31 16:21:52 bm,yNi1e4fsAClDv7lNxxSfJ
>>> lrwxrwxrwx  framstag users        - 2017-06-01 15:53:00 GZxNYI0Gy96R18fz40f7k5rl -> wvuQKHYzdFbar18fW6jjOerXk2IsS4OAA2fnHalBZjMQ,7Kw0j-zE3IJqxhmmGBN8G9
>>> -rw-r--r--  framstag users      182 2016-12-01 13:34:31 rqtNBbiYDym0hPMbBL-VLJZcFZu6nkNxlsjTX-sU88I4I1
>>>
>>> I have to mount the snapshot with encfs, to have access to the (decrypted)
>>> files.
>>>
>>> Any better ideas?
>>
>>     I'd say it's doing exactly what it should be doing. You're making a
>> copy of an encrypted data store,
> 
> With all respect - snapshot is not a copy.
 From a userspace perspective, it is, and that's what matters since 
EncFS is a userspace tool.  In fact, part of the point of a snapshot is 
that it's functionally indistinguishable from a direct copy of the data 
unless you start looking at block layouts (which nothing in userspace 
that isn't an administration tool should be doing).
> 
>> and the result is encrypted. In order
>> to read it, it needs to have the decrpytion layer applied to it with
>> the correct key (which is the need to mount the snapshot with encfs).
>>
> 
> But snapshot *is* mounted implicitly as it is part of mounted btrfs
> filesystem. So I can see that this behavior could be rather unexpected.
> 
>>     Would you _really_ want a system where the encrypted contents of a
>> subvolume can be decrypted by simply snapshotting it?
> 
> The actual question is - do you need to mount each individual btrfs
> subvolume when using encfs? If yes, this behavior is at least
> consistent. If not - how are snapshots different?
I think you're not understanding the layering here.  EncFS is a FUSE 
filesystem that is run as a separate layer on top of another filesystem. 
  It is completely agnostic of the underlying data storage 
implementation, provided that said data storage enforces POSIX I/O 
semantics.

To clarify, the procedure for mounting an EncFS volume is:
1. Mount the underlying filesystem (usually done at boot by the init 
system).
2. Mount the EncFS instance that is using that underlying filesystem as 
storage (usually done on user log-in by the session manager or PAM).

On BTRFS, step 1 is implicit if it's a subvolume, but step 2 is never 
implicit, regardless of the filesystem.  Hugo's mention of needing 
mounting the snapshot with EncFS refers to the second step here, not the 
first.

Re: snapshots of encrypted directories?

[Andrei Borzenkov]

15.09.2017 15:35, Austin S. Hemmelgarn пишет:
> On 2017-09-14 23:45, Andrei Borzenkov wrote:
>> 14.09.2017 18:32, Hugo Mills пишет:
>>> On Thu, Sep 14, 2017 at 04:57:39PM +0200, Ulli Horlacher wrote:
>>>> I use encfs on top of btrfs.
>>>> I can create btrfs snapshots, but I have no suggestive access to the
>>>> files
>>>> in these snaspshots, because they look like:
>>>>
>>>> drwx------  framstag users        - 2017-09-08 11:47:18
>>>> uHjprldmxo3-nSfLmcH54HMW
>>>> drwxr-xr-x  framstag users        - 2017-09-08 11:47:18
>>>> wNEWaDCgyXTj0d-Myk8wXZfh
>>>> -rw-r--r--  framstag users      377 2015-06-12 14:02:53
>>>> -zDmc7xfobKDkbl8z7oKOHxv
>>>> -rw-r--r--  framstag users    2,367 2012-07-10 14:32:30
>>>> 7pfKs27K9k5zANE4WOQEuFa2
>>>> -rw-------  framstag users      692 2009-10-20 13:45:41
>>>> 8SQElYCph85kDdcFasUHybVr
>>>> -rw-------  framstag users    2,872 2017-08-31 16:21:52
>>>> bm,yNi1e4fsAClDv7lNxxSfJ
>>>> lrwxrwxrwx  framstag users        - 2017-06-01 15:53:00
>>>> GZxNYI0Gy96R18fz40f7k5rl ->
>>>> wvuQKHYzdFbar18fW6jjOerXk2IsS4OAA2fnHalBZjMQ,7Kw0j-zE3IJqxhmmGBN8G9
>>>> -rw-r--r--  framstag users      182 2016-12-01 13:34:31
>>>> rqtNBbiYDym0hPMbBL-VLJZcFZu6nkNxlsjTX-sU88I4I1
>>>>
>>>> I have to mount the snapshot with encfs, to have access to the
>>>> (decrypted)
>>>> files.
>>>>
>>>> Any better ideas?
>>>
>>>     I'd say it's doing exactly what it should be doing. You're making a
>>> copy of an encrypted data store,
>>
>> With all respect - snapshot is not a copy.
> From a userspace perspective, it is, and that's what matters since EncFS
> is a userspace tool.  In fact, part of the point of a snapshot is that
> it's functionally indistinguishable from a direct copy of the data
> unless you start looking at block layouts (which nothing in userspace
> that isn't an administration tool should be doing).
>>
>>> and the result is encrypted. In order
>>> to read it, it needs to have the decrpytion layer applied to it with
>>> the correct key (which is the need to mount the snapshot with encfs).
>>>
>>
>> But snapshot *is* mounted implicitly as it is part of mounted btrfs
>> filesystem. So I can see that this behavior could be rather unexpected.
>>
>>>     Would you _really_ want a system where the encrypted contents of a
>>> subvolume can be decrypted by simply snapshotting it?
>>
>> The actual question is - do you need to mount each individual btrfs
>> subvolume when using encfs? If yes, this behavior is at least
>> consistent. If not - how are snapshots different?
> I think you're not understanding the layering here.  EncFS is a FUSE
> filesystem that is run as a separate layer on top of another filesystem.
>  It is completely agnostic of the underlying data storage
> implementation, provided that said data storage enforces POSIX I/O
> semantics.
> 

I did understand layering but I was not familiar with subtleties. I now
tested encfs with subvolumes and subvolumes, present in encrypted
directory, are not visible in unencrypted directory at all (and of
course I cannot create subvolume on overlay mount). But - if I know
encrypted name I can create subvolume with the same name - and it
becomes visible under cleartext mount:

bor@10:~> /usr/sbin/btrfs sub cre .encfs/CxRowQNCTNP3Bm0DlEFADnj5
Create subvolume '.encfs/CxRowQNCTNP3Bm0DlEFADnj5'
bor@10:~> ll .encfs/
total 0
drwxr-xr-x 1 bor users 0 Sep 15 20:18 CxRowQNCTNP3Bm0DlEFADnj5
drwxr-xr-x 1 bor users 0 Sep 15 20:11 sub2
bor@10:~> encfs ~/.encfs ~/encfs
EncFS Password:
bor@10:~> ll encfs/
total 0
drwxr-xr-x 1 bor users 0 Sep 15 20:18 sub1
bor@10:~> mkdir encfs/sub1/even-deeper
bor@10:~> ll .encfs/
total 0
drwxr-xr-x 1 bor users 48 Sep 15 20:19 CxRowQNCTNP3Bm0DlEFADnj5
drwxr-xr-x 1 bor users  0 Sep 15 20:11 sub2
bor@10:~> ll .encfs/CxRowQNCTNP3Bm0DlEFADnj5/
total 0
drwxr-xr-x 1 bor users 0 Sep 15 20:19 Z4yelS9xOwbOxZ0tGxopma8K
bor@10:~>

That is what I meant - subvolumes themselves are transparent as long as
you can traverse them. So if they remain under the encfs mount root and
have names that encfs can decode, it is possible to reach them.

> To clarify, the procedure for mounting an EncFS volume is:
> 1. Mount the underlying filesystem (usually done at boot by the init
> system).
> 2. Mount the EncFS instance that is using that underlying filesystem as
> storage (usually done on user log-in by the session manager or PAM).
> 
> On BTRFS, step 1 is implicit if it's a subvolume, but step 2 is never
> implicit, regardless of the filesystem.  Hugo's mention of needing
> mounting the snapshot with EncFS refers to the second step here, not the
> first.