ZFS snapdir readability (Crosspost)

[Borja Marcos]

> On 20 Nov 2019, at 17:58, Jan Behrens <jbe-mlist at magnetkern.de> wrote:
> 
> 
> With "mounting snapshots", I meant mounting snapshots that are already
> existent in a ZFS pool. Receiving a snapshot and creating a new
> filesystem from it is a different issue. In that case, you can use
> "zfs receive -u" and mount the file system manually under a directory with
> a parent directory that is chmod 700, as in option (d).

What I mean is, there is no snapshot mount functionality. If you want to access the
contents of a snapshot you either rollback it or you clone it. There is no mount. Or of
course you access the “.zfs" directory.

Which makes me realize that the “.zfs" directory feature is an odd anomaly (ie
a bloody kludge) in an otherwise really clean and consistent design.

Why?

1. There is no accessible facility for the read only mount of a snapshot. Yet
the system mounts them by default.

2. Because of (1) you can’t control where to mount them. They are mounted
there. Period. 

3. You can’t prevent it. You can hide the .zfs directory but its’s still there,
with the snapshots mounted. 


> Mounting is not the same as cloning and mounting. But you are right: If
> snapshots are cloned first, you can specify the mountpoint. But then
> you are mounting a new file system and not a snapshot technically.
> Which brings us back to option (a) never mount snapshots ever ;-)
> 
> Given that we can prohibit the automounting of all snapshots, it would
> be a nice workaround which would not have too much overhead.

I would rather prefer if that option didn’t exist. Given that it can’t be removed now
because it would surely break someone’s work, the most important tweak that
can be done is to allow the administrator to supress it completely. 

So, zfs set snapdir=disabled. 

Limiting it by uid won’t necessarily be enough as you should also take into
account systems in which different securty enforcement mechanisms are used.
(MAC policies like mls, biba, etc). And adding a generalized way to deal with
this would probably be too complex. 









Borja.