Date: Thu, 21 Nov 2019 11:19:28 GMT From: Martin Simmons <martin@lispworks.com> To: Jan Behrens <jbe-mlist@magnetkern.de> Cc: borjam@sarenet.es, freebsd-fs@freebsd.org Subject: Re: ZFS snapdir readability (Crosspost) Message-ID: <201911211119.xALBJSIW030544@higson.cam.lispworks.com> In-Reply-To: <20191120175803.03401c3316fe756cc46f79f1@magnetkern.de> (message from Jan Behrens on Wed, 20 Nov 2019 17:58:03 %2B0100) 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 Wed, 20 Nov 2019 17:58:03 +0100, Jan Behrens said: > > On Wed, 20 Nov 2019 17:07:44 +0100 > Borja Marcos <borjam@sarenet.es> wrote: > > > > On 20 Nov 2019, at 16:34, Jan Behrens <jbe-mlist@magnetkern.de> wrote: > > > > > > [...] 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. > > > > True. > > > > > The latter requires to either > > > (a) never mount snapshots ever, or > > > > Well, they are useful for a reason :) > > > > > (b) only mount snapshots when they are to be *completely* restored, or > > > > Cloning is atomic. Receiving a snapshot stream, sorry, I don’t remember :/ > > 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). > > > > > > (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. > > > > Well, there are two options here. > > > > If by restoring snapshots you mean receiving a snapshot stream, you can always receive it under > > a properly protected dataset. > > I did not mean receiving a snapshot stream, see above. > > > If you intend to mount (ie, clone) it the solution is the same. Actually > > specifying a mount point when cloning a snapshot is mandatory. You are actually creating a dataset. > > > > root@micro1:~ # zfs create unpul/forbidden > > root@micro1:~ # chmod go-rwx /unpul/forbidden/ > > > > Anything I restore or clone under this dataset will be only accessible to root. > > > > For example: > > > > root@micro1:~ # zfs clone unpul/UniFi/data@5.11.38 unpul/forbidden/testing > > > > (now back to a regular user) > > > > borjam@micro1:/unpul % cd /unpul/forbidden/ > > /unpul/forbidden/: Permission denied. > > > > Anyway this is not a problem, it’s exactly what you would do if you were reading a tape. > > > > The real problem is the “unexpected”, automatic, unavoidable mounting of the .zfs directory. > > > > Or am I missing anything? > > > > Borja. > > 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. Can't you already achieve (d) using /sbin/mount? __Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201911211119.xALBJSIW030544>