Date: Thu, 21 Nov 2019 13:12:04 +0100 From: Borja Marcos <borjam@sarenet.es> To: Jan Behrens <jbe-mlist@magnetkern.de> Cc: Mike Tancsa <mike@sentex.net>, Alan Somers <asomers@freebsd.org>, freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: ZFS snapdir readability (Crosspost) Message-ID: <3C5DC6DD-C44B-41EE-B7AB-6D8F94E43174@sarenet.es> In-Reply-To: <20191120175803.03401c3316fe756cc46f79f1@magnetkern.de> References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <CAOtMX2huHZcXHH%2B=3Bx7hX_p9udJ2acOX%2BZL8vW=pjqbe6mOAA@mail.gmail.com> <e2eecef7-21b6-0ff2-b259-71421b7d097c@sentex.net> <9B22AD46-BE87-4305-9638-74D23AD4C8CA@sarenet.es> <cfcc12dd-e9eb-5a98-a031-ab18436a2dd3@sentex.net> <261FE331-EC5C-48C8-9249-9BCBF887CE38@sarenet.es> <913f7040-6e38-452d-6187-e17fae63b652@sentex.net> <20191120144041.7f916360dc0c69bf509c9bd1@magnetkern.de> <AEF4CA02-36B3-42FC-BE92-14DF0AF99540@sarenet.es> <20191120163437.691abd369ab9c0a6d7d45ff2@magnetkern.de> <CF38B478-3638-4C18-B69F-E589DE9BBB95@sarenet.es> <20191120175803.03401c3316fe756cc46f79f1@magnetkern.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 20 Nov 2019, at 17:58, Jan Behrens <jbe-mlist@magnetkern.de> wrote: >=20 >=20 > 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 =E2=80=9C.zfs" directory. Which makes me realize that the =E2=80=9C.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=E2=80=99t control where to mount them. They = are mounted there. Period.=20 3. You can=E2=80=99t prevent it. You can hide the .zfs directory but = its=E2=80=99s still there, with the snapshots mounted.=20 > 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 ;-) >=20 > 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=E2=80=99t exist. Given that it = can=E2=80=99t be removed now because it would surely break someone=E2=80=99s work, the most important = tweak that can be done is to allow the administrator to supress it completely.=20 So, zfs set snapdir=3Ddisabled.=20 Limiting it by uid won=E2=80=99t 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.=20 Borja.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C5DC6DD-C44B-41EE-B7AB-6D8F94E43174>