ZFS snapdir readability (Crosspost)

[Jan Behrens]

> On Wed, Nov 6, 2019 at 4:46 PM Jan Behrens <jbe-mlist at magnetkern.de> wrote:
> 
> > I recently noticed that all ZFS filesystems in FreeBSD allow access to
> > the .zfs directory (snapdir) for all users of the system.

On Wed, 6 Nov 2019 17:02:14 -0700
Alan Somers <asomers at freebsd.org> wrote:

> Your analysis of the snapdir is correct.  Setting it to hidden doesn't make
> it inaccessible.  That's not unique to FreeBSD, however.  I believe it's
> common to all ZFS implementations (I just double checked on Oracle
> Solaris).

I already suspected that this might be an issue originating from ZFS
itself (and not be FreeBSD specific). Thank you for the research (I
don't have a Solaris system at hand ;-)

> Also, the problem isn't unique to ZFS.  Any backup system would
> have the same problem, as long as users are allowed to access the backups
> directly.

My problem here is that with most (or maybe even all) other backup
systems, I would be able to restrict ordinary users from accessing all
backups. So I consider this problem to be pretty much unique to ZFS
(unless I misunderstood your point?)

> And in fact, Bob could've directly observed Alice's id_rsa file
> before she changed it.  So I don't think this should be considered a
> security vulnerability.  The best course for Alice would be to consider her
> id_rsa as compromised as soon as she notices the problem, and delete it.
>
> -Alan

I already foresaw this argument and mentioned a possible
counter-argument:

> > Of course, one could argue that Alice shouldn't have made the mistake
> > in the first place. Nonetheless, I consider it to be a security issue
> > if regular snapshots cause files which were once publicly readable to
> > be always readable (as long as certain snapshots exist). Moreover, a
> > user might want to deliberatly block access to a file that was
> > intendedly public before.

There could be several examples (other than an ssh key file) where
someone wants to restrict access to a previously publicly readable file
(whether it was deliberately publicly readable or accidentally publicly
readable). 

Regards
Jan