ZFS snapdir readability (Crosspost)

Jan Behrens jbe-mlist at magnetkern.de
Fri Nov 8 11:52:39 UTC 2019

On Thu, 7 Nov 2019 08:37:15 +0200
Andriy Gapon <avg at FreeBSD.org> wrote:

> On 07/11/2019 04:36, Jan Behrens wrote:
> > [...]
> > 
> > Not all application fields of snapshots, however, (whether backup or
> > replication or other) have the purpose of letting non-privileged users
> > access the data. With the current implementation of ZFS I have no
> > choice on whether I want this behavior or consider it a security
> > problem that should be avoided in my scenario. This also applies to
> > snapshots taken for other reasons than (user readable) backups.
> It's an interesting problem.
> My take is that snapshots are snapshots and that's how they are.
> If you don't like how they work and you actually only need backups, then you can
> take backups.  E.g., take a snapshot, send it (either full or incremental) to a
> backup file in a secure location or to a secure backup system, create a bookmark
> for the snapshot -- if you will need future incremental snapshots, destroy the
> snapshot.
> No snapshots, no .zfs issues :)
> -- 
> Andriy Gapon

That is interesting, I didn't understand the concept of bookmarks
before. This would solve the problem of needing to keep snapshots
around on the originating server when some data has not been replicated
to all destinations yet.

It solves the problem of having accidentally readable files sticking
around for more than a few seconds if the snapshots (or rather:
bookmarks) are created for purposes of replication only.

Still, this solution implies either
* using snapshots *only* to create bookmarks and deleting them right
  afterwards, or
* dealing with the security issues mentioned in my original post.

Of course, "take as is or don't use it" is a valid approach to avoid
using insecure software, but I believe adding an option to restrict
readability of .zfs/snapdir to the owner of the root would
significantly improve security, especially as some operators might not
even be aware of the risks. (This issue has been lurking around for
years, see the link posted by Mike


More information about the freebsd-fs mailing list