ZFS snapdir readability (Crosspost)

[Jan Behrens]

On Wed, 20 Nov 2019 16:02:14 +0100
Borja Marcos <borjam at sarenet.es> wrote:

> > On 20 Nov 2019, at 14:40, Jan Behrens <jbe-mlist at magnetkern.de> wrote:
> > 
> > On Wed, 20 Nov 2019 08:24:43 -0500
> > Mike Tancsa <mike at sentex.net> wrote:
> > 
> >> Actually, thats all I am advocating for-- settings perms on the
> >> accessibility of the snapshot. ie instead of the "invisibility" feature,
> >> change it to an "inaccessible" feature.
> >> 
> >>     ---Mike
> > 
> > This would solve the security problem, but only as long as snapshots are
> > never mounted. Once they are mounted (unless you can specify the
> > directory where they are mounted), unprivileged users could still
> > access files they should not be allowed to access.
> > 
> > A better solution would be to specify user, group, and modes
> > (e.g. root:root 700) when mounting or auto-mounting snapshots.
> 
> At least it’s a different problem. Mounting a snapshot *intentionally* could be
> something similar to recovering a backup. What poses a serious issue in my
> opinion is that the system *does* mount them automatically. 
> 
> Borja.
> 

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
(b) only mount snapshots when they are to be *completely* restored, or
(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.

Regards,
Jan