ZFS snapdir readability - feature request or security issue?
jbe-mlist at magnetkern.de
Sun Oct 27 11:27:38 UTC 2019
I recently noticed that all ZFS filesystems in FreeBSD allow access to
the .zfs directory (snapdir) for all users of the system. It is
possible to hide that directory using the snapdir option:
snapdir=hidden | visible
Controls whether the .zfs directory is hidden or visible in the root
of the file system as discussed in the "Snapshots" section. The
default value is hidden.
However, setting snapdir=hidden will only "hide" the directory from
"ls". It is still possible to access that directory, also as a
It seems to be impossible to restrict access to this directory. Calling
chmod 700 /.zfs results in "chmod: /.zfs: Operation not supported".
Given the immutability of snapshots, the directories and files will
have access rights from the point in time when the snapshot was taken.
Considering a system that creates snapshots regularly (e.g. for backup
or replication purposes), this could lead to security issues, as I
would like to illustrate with the following example:
Consider a user (Alice) who accidentally created a file
/usr/home/alice/.ssh/id_rsa as publicly readible, but who notices
shortly after that this was a mistake. Alice fixes her mistake by
calling: chmod 600 /usr/home/alice/.ssh/id_rsa
If in the meantime a snapshot zroot/usr/home at 2019-10-27 was taken,
which is intended to be kept for a longer time, then Bob will be able
to access Alice's private SSH key through the
As far as I understand, there is no (clean) way to prohibit this, except
deleting the whole snapshot (which might not be desirable in all
scenarios). Note that:
su - root
chmod 700 /usr/home/.zfs => Operation not supported
chmod 700 /usr/home/.zfs/snapshot => Operation not supported
chmod 700 /usr/home/.zfs/snapshot/2019-10-27 => Read-only file system
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.
One (dirty) workaround I was able to figure out is to do a
mount_nullfs /var/empty /usr/home/.zfs which results in the following
- /usr/home/.zfs is still hidden
- /usr/home/.zfs is empty for all users (root and non-privileged users)
I was able to improve this by doing:
mkdir -p /usr/home/protected/snapshot
chmod 700 /usr/home/protected
mount_nullfs /usr/home/.zfs/snapshot /usr/home/protected/snapshot
mount_nullfs /var/empty /usr/home/.zfs
This way, the root user can access the snapshot directory
through /usr/home/protected/snapshot while all other users should
(hopefully) not be able to gain access to snapshot data. This
workaround, however, has several drawbacks:
- Considering a larger number of ZFS filesystems on an average system
(my system came with 14 file systems by default), this will bloat the
output of "mount" and easily cause confusion.
- There can be race conditions when mounting a previously unmounted ZFS
filesystem, such that for a small moment (after mounting the ZFS file
system and before doing the nullfs mount), a malicious user could
access the hidden .zfs directory.
- Using the default commands, it is likely to accidentally forget the
nullfs mount and leave the snapdir exposed to non-privileged users.
Is there any other method to prohibit non-privileged users from
accessing the ZFS snapdir? If not, I would propose to add one. I'm not
even sure if this is a feature request or rather fixing a security
vulnerability as explained in the Alice & Bob example above.
More information about the freebsd-questions