Date: Wed, 20 Nov 2019 17:58:03 +0100 From: Jan Behrens <jbe-mlist@magnetkern.de> To: Borja Marcos <borjam@sarenet.es> 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: <20191120175803.03401c3316fe756cc46f79f1@magnetkern.de> In-Reply-To: <CF38B478-3638-4C18-B69F-E589DE9BBB95@sarenet.es> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Regards, Jan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191120175803.03401c3316fe756cc46f79f1>