a way to disable automouting snapshots via access to .zfs dir

[jelinekr]

Hi,

is there is a way to disable automouting snapshots when being accessed via .zfs directory? We need this for security reasons in cases where a too permissive dirent entry gets fixed, the vulnerability is still present and accessible in older snapshots. The "snapdir" zfs property only allows hiding the directory from readdir(3), but it doesn't prevent automounting snapshots when it's accessed. Can we add something similar to zfs_expire_snapshot variable (i.e. zfs_disable_snapshot_automount or zfs_snapshot_canmount) for this?

Thanks,
Rob

[behlendorf]

@jelinekr I'm surprised this hasn't come up before. Right now there's no way to disable .zfs snapshot automounting but I definitely agree there should be. For the moment you'll need to disable it at build time. Probably the best way to do this is to #undef HAVE_AUTOMOUNT in the zfs_config.h after running configure.

As for how to support this I think extending the snapdir property is the logical thing to do. How about adding a disabled option. Where disabled means exactly what you'd expect it to mean, the .zfs directory just won't exist.

       snapdir=hidden | visible | disabled

[chjohnst]

I like that proposal
On Dec 8, 2015 7:40 PM, "Brian Behlendorf" notifications@github.com wrote:

@jelinekr https://github.com/jelinekr I'm surprised this hasn't come up
before. Right now there's no way to disable .zfs snapshot automounting
but I definitely agree there should be. For the moment you'll need to
disable it at build time. Probably the best way to do this is to #undef
HAVE_AUTOMOUNT in the zfs_config.h after running configure.

As for how to support this I think extending the snapdir property is the
logical thing to do. How about adding a disabled option. Where disabled
means exactly what you'd expect it to mean, the .zfs directory just won't
exist.

   snapdir=hidden | visible | disabled

—
Reply to this email directly or view it on GitHub
#3963 (comment).

[jelinekr]

Me too, thanks for looking into this.

-----Original Message-----
From: Christopher Johnston [mailto:notifications@github.com]
Sent: Tuesday, December 08, 2015 07:59 PM Eastern Standard Time
To: zfsonlinux/zfs
Cc: Robert Jelinek
Subject: Re: [zfs] a way to disable automouting snapshots via access to .zfs dir (#3963)

I like that proposal
On Dec 8, 2015 7:40 PM, "Brian Behlendorf" notifications@github.com wrote:

@jelinekr https://github.com/jelinekr I'm surprised this hasn't come up
before. Right now there's no way to disable .zfs snapshot automounting
but I definitely agree there should be. For the moment you'll need to
disable it at build time. Probably the best way to do this is to #undef
HAVE_AUTOMOUNT in the zfs_config.h after running configure.

As for how to support this I think extending the snapdir property is the
logical thing to do. How about adding a disabled option. Where disabled
means exactly what you'd expect it to mean, the .zfs directory just won't
exist.

snapdir=hidden | visible | disabled

—
Reply to this email directly or view it on GitHub
#3963 (comment).

—
Reply to this email directly or view it on GitHub #3963 (comment) . https://github.com/notifications/beacon/AOo7wVnJZfBdZ251U_RbwJmC4NvdWnzZks5pN3SGgaJpZM4GW5aq.gif

---

This communication is intended only for the addressee(s), may contain confidential, privileged or proprietary information, and may be protected by US and other laws. Your acceptance of this communication constitutes your agreement to keep confidential all the confidential information contained in this communication, as well as any information derived by you from the confidential information contained in this communication. We do not waive any confidentiality by misdelivery.

If you receive this communication in error, any use, dissemination, printing or copying is strictly prohibited; please destroy all electronic and paper copies and notify the sender immediately. Nothing in this email is intended to constitute (1) investment or trading advice or recommendations or any advertisement or (2) a solicitation of an investment in any jurisdiction in which such a solicitation would be unlawful.

Please note that PDT Partners, LLC, including its affiliates, reserves the right to intercept, archive, monitor and review all communications to and from its network.

[ilovezfs]

What would be the expected behavior, while snapdir=disabled is set, when a user tries to mkdir .zfs and possibly populate it with data?

[behlendorf]

Good question, I suppose it will need to fail with a reasonable errno to ensure snapdir can be safely enabled again if desired.

[ilovezfs]

@behlendorf That makes sense. Another issue is whether it makes sense to have the snapdir property controlling .zfs or .zfs/snapshot. It feels like a mistake to conflate snapdir and ctldir. Would it make more sense to have a) two separate properties, snapdir and sharedir, b) three separate properties, snapdir, sharedir, and ctldir, c) just snapdir and ctldir, since a specific need for a separate sharedir property has yet to arise other than in this context, or d) something else?

Yet, I suppose the snapdir property hidden/visible has already conflated them, so it may be fine to continue that practice. However, when snapdir=hidden, both .zfs/snapshot and .zfs/shares are actually still available. With snapdir=disabled, I guess both would become unavailable for the sake of preventing the snapshot automounting, possibly making .zfs/shares "collateral damage" depending on the user's intent. Or would you want to leave .zfs/shares access in tact even when snapdir=disabled?

As for errnos, currently mkdir .zfs{,/snapshot,/shares} all set the exit status to 1 and print a "File exists" error, and touch .zfs{,/snapshot,/shares} all succeed with exit status 0. Strangely, touch .zfs actually updates the timestamp (Is this a bug?), while touch .zfs/snapshot and .zfs/shares do not update the time stamps despite the 0 exit statuses.

[behlendorf]

This issue was addressed in master by adding support for zfs allow in commit f74b821. Enforcement is now done through delegations which is consistent with the other OpenZFS platforms. The zfs_admin_snapshot was left in place for backwards compatibility.

[wl2018]

Sorry, could you tell how to use zfs allow to disable or restrict access to .zfs snapshot dir? After searching and looking references in Internet, I still don't know how to do.

[pgassmann]

@behlendorf how does zfs allow resolve this issue?

I was surprised that the snapdirs are accessible even with snapdir=hidden. To me it seems very strange that something is there but is not listed. that's not something I knew was possible (on Linux)

This could be a potential data protection/privacy issue if data that should be deleted is still accessible to applications/containers.
Additionally through the snapdirs, data could be accessible that are otherwise overmounted. (bad design)

If a ZFS filesystem is mounted into a docker container, the snapdirs are available from within the container.

EDIT: The snapshots can be listed, but the content is not accessible. (At least in my case):

/ # ls -lah /data/.zfs/snapshot/migrate20210510/ -alh
ls: /data/.zfs/snapshot/migrate20210510/: Symbolic link loop

I assume many zfs users are not aware of that doubly-hidden but still available .zfs path and expect snapdir=hidden means not available

[JanBeh]

@behlendorf how does zfs allow resolve this issue?

I don't think resolves this issue. This issue (#3963) should be reopened, see also #9028.

[behlendorf]

Reopening. Thanks for revisiting this, we should provide a mechanism to at least disable the snapshot directories.

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.