.zfs/snapshots privileges settings

[montanaviking]

System information

Type	Version/Name
Distribution Name
Distribution Version
Linux Kernel
Architecture
ZFS Version
SPL Version

Describe the problem you're observing

Describe how to reproduce the problem

Include any warning/errors/backtraces from the system logs

[montanaviking]

Distribution name: Ubuntu 18.04
Version 18.04
Linux Kernel: 4.15.0-54-generic
Architecture: Intel Xeon 64-bit
ZFS version: 0.7.5-1ubuntu16.4
SPL version: 0.7.5-1ubuntu

Checking privileges on .zfs/snapshot shows all users, including guest, have all privileges.
I presume that this is a security hole. Also, I'm hoping that nobody can directly delete the snapshots.
How do I ensure that only root may read the snapshots?
Thanks and best,
Phil

[kusumi]

I think it's missing inode_init_owner(..., vap->va_mode) on mkdir, but mkdir/rmdir/rename for ctldir all require CAP_SYS_ADMIN anyway.

[devZer0]

everything below .zfs/snapshot is readlony, regardless was permission is shown - so this should be a "non issue"

you can try adding or remove files there and will see that you won't succeed

How do I ensure that only root may read the snapshots?

why?

if anybody could read /zpool/mydir - why would you want to disallow access to /zpool/.zfs/snapshots/$snapname/mydir ?

[eharris]

One potential issue I can see immediately is that if a there was a security issue where something was visible to users in the past when a snapshot was created, but has since been corrected. Since the snapshot can't be modified to also fix the permissions, how can you reasonably handle this without a way to restrict access to the problematic snapshot?

[JanBeh]

One potential issue I can see immediately is that if a there was a security issue where something was visible to users in the past when a snapshot was created, but has since been corrected.

Mistakes in the past are not the only problem. Another problem is when privileges change over time, e.g. because security is tightened or because changing privileges due to other reasons (e.g. users are added to a group, and those group's privileges are changed).

The current behavior makes it impossible to revoke reading privileges for a user or group (unless destroying all snapshots), both in the case of "mistakes" or of ordinary change of privileges for a user or group.

[behlendorf]

The recommended solution is this case would be to destroy any effected snapshots.

[eharris]

Being forced to destroy an entire snapshot, and all the value/data that it has, simply to secure a tiny portion of it is not a solution. Unless there's some way to edit snapshots, which isn't yet available as far as I know, is it?

[behlendorf]

Editing snapshots isn't really possible, but providing some administrative controls regarding how they can be used would be. For example, disabling the .zfs/snapshots directory for a dataset. Or perhaps change the default permissions on the mount point. Did you have a specific solution in mind for this?

Note: I've gone ahead and migrated this issue to the new "Ideas" tab in the Discussions tab which we've just enabled to better track and discuss these kind of feature requests.

[eharris]

To me, it seems like there should be a per-snapshot property that controls whether the snapshot is accessible via the .zfs/snapshot/ directory. And a per-filesystem property that sets the default value of this property for newly created snapshots of that filesystem. This way admins can decide either to allow access to all snapshots (with the ability to exclude certain "sensitive" ones), or restrict all snapshots but the specific ones they have allowed.

[almereyda]

Reading through zfsconcepts(8) states:

The visibility of the .zfs directory can be controlled by the snapdir property.

This is specified by zfsprops(8) and reads:

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 of zfsconcepts(8). The default value is hidden.

The documentation does not state the property can be set to disabled, as suggested before. Am I misinterpreting something? Or is that an additional value we intend to introduce here? This property could then also be delegated by a zpool's root dataset to its childs. For completely hiding datasets with the hidden or visible settings, I guess, it would have to be mutated during snapshot creation, if (1) snapshots are immutable and (2) a desired snapshot is not intended to be visible in the filesystem at all. Is that even possible? The snapdir logic could then omit it from the .zfs/snapshot directory listings.

[behlendorf]

The documentation does not state the property can be set to disabled, as suggested before. Am I misinterpreting something?

That's right. Only the hidden and visible options as documented are currently supported. Adding a new disabled or off setting would potentially be a reasonable way to restrict access. However, like hidden and visible it would apply to all of the snapshots for a filesystem. Since snapshots are immutable doing something more granual is significantly more involved.

One possibility that might be interesting would be to see if we can apply "redaction bookmarks" to the snapshots in the .zfs/snapshot directory. If you're not familiar, this an existing mechanism which can be used to redact sensitive blocks from a zfs send stream of a snapshot. You can imagine applying this same redaction locally to a mounted snapshot.

[JanBeh]

I see a potential security problem here, also because current behavior may be unexpected for some administrators. At the least, it's a usability problem because snapshots have to be destroyed whenever privileges change on a system.

This problem has been around for years now, and I think that there should either be a clean solution (e.g. being able to set file modes for the .zfs or .zfs/snapshot directory, or user+mode on a per snapshot basis) or a reasonable workaround by allowing to simply disable access to snapshots for all non-root users.

The latter may not be the best option, but it's better than keeping this problem open even longer (and restricting access to the root user should not be too difficult to implement, I guess?).

I wasn't aware of this discussion previously but recently created a bug ticket for FreeBSD because I consider this a serious bug that is difficult to work around (one workaround for FreeBSD is to shadow the .zfs directory with mount_nullsfs, but it's pretty dirty and error prone).

[JanBeh]

Is there an issue report open here too? I didn't find one. This discussion is under "ideas", but I think it is a real issue and should be treated as such.

[JanBeh]

Is there an issue report open here too? I didn't find one.

There is #3963 (open since 2015!), but it has been closed by @behlendorf. However, I don't think this issue has been fixed. That bug should be reopened.

I also found an old thread I started on a FreeBSD mailinglist on this topic.