ZFS snapdir readability (Crosspost)

[Borja Marcos]

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

True. 

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

For example:

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? 



Borja.