ZFS snapdir readability (Crosspost)
borjam at sarenet.es
Wed Nov 20 16:07:51 UTC 2019
> On 20 Nov 2019, at 16:34, Jan Behrens <jbe-mlist at magnetkern.de> wrote:
> Security vulnerabilities during backup recovery (e.g. when recovering
> part of the backup but being forced to expose other data as well when
> mounting the system) are still security vulnerabilities. Of course
> limiting the security vulnerabilities to certain moments (partial
> backup recovery) is a nice step forward, but an even better solution
> would be to avoid security vulnerabilities at all times.
> The latter requires to either
> (a) never mount snapshots ever, or
Well, they are useful for a reason :)
> (b) only mount snapshots when they are to be *completely* restored, or
Cloning is atomic. Receiving a snapshot stream, sorry, I don’t remember :/
> (c) be able to specify the user, group, and mode (unless 700 by
> default) when mounting or auto-mounting the snapshots, or
> (d) be able to specify a mount point such that the mount point can be
> within a directory that is not +x for everyone.
Well, there are two options here.
If by restoring snapshots you mean receiving a snapshot stream, you can always receive it under
a properly protected dataset. If you intend to mount (ie, clone) it the solution is the same. Actually
specifying a mount point when cloning a snapshot is mandatory. You are actually creating a dataset.
root at micro1:~ # zfs create unpul/forbidden
root at micro1:~ # chmod go-rwx /unpul/forbidden/
Anything I restore or clone under this dataset will be only accessible to root.
root at micro1:~ # zfs clone unpul/UniFi/data at 5.11.38 unpul/forbidden/testing
(now back to a regular user)
borjam at micro1:/unpul % cd /unpul/forbidden/
/unpul/forbidden/: Permission denied.
Anyway this is not a problem, it’s exactly what you would do if you were reading a tape.
The real problem is the “unexpected”, automatic, unavoidable mounting of the .zfs directory.
Or am I missing anything?
More information about the freebsd-fs