Date: Wed, 16 Aug 2017 12:12:18 +0200 From: Borja Marcos <borjam@sarenet.es> To: Mike Tancsa <mike@sentex.net> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: protecting zfs snapshot info Message-ID: <003E0B0C-95C5-4D0B-91DB-393877480BDE@sarenet.es> In-Reply-To: <b911a1d7-02ae-c16e-2534-f7b1b44215f7@sentex.net> References: <d7fa3f0c-e00a-9c41-5430-1f381f71d3e0@sentex.net> <52984307-2C6C-454C-A69B-15FB4AE01E1B@sarenet.es> <5e3145ab-246a-f213-80b0-000dd801fbef@sentex.net> <b911a1d7-02ae-c16e-2534-f7b1b44215f7@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 15 Aug 2017, at 14:20, Mike Tancsa <mike@sentex.net> wrote: >=20 > On 8/14/2017 8:57 AM, Mike Tancsa wrote: >> On 8/14/2017 2:47 AM, Borja Marcos wrote: >>>=20 >>>> On 12 Aug 2017, at 19:14, Mike Tancsa <mike@sentex.net> wrote: >>>>=20 >>>>=20 >>>> Is there a way in zfs to protect non root users from seeing = snapshots ? >=20 >>> Good question and it=E2=80=99s a problem indeed. The .zfs directory = is always created >>> and it can be hidden but it=E2=80=99s still accessible. It=E2=80=99s = a security problem that prevents >>> an effective access revocation for a directory/file, I guess = that=E2=80=99s what you mean. >>=20 >> Yes, something like an extra option >> hidden | visible | unmounted >=20 > I did come across this thread >=20 > https://github.com/zfsonlinux/zfs/issues/3963 >=20 > but it seems Linux specific or at least I dont see how its done on = FreeBSD. Yes, it seems to be Linux specific and as far as I know there=E2=80=99s = no way to do it on FreeBSD right now. I would vouch for a third state added to the =E2=80=9Csnapdir=E2=80=9D = variable, but I wouldn=E2=80=99t call it =E2=80=9Cdisabled=E2=80=9D. = =E2=80=9Cunmounted=E2=80=9D or maybe =E2=80=9Cnoauto=E2=80=9D is much better in my opinion. The .zfs = directory should still be created (maybe hidden when in =E2=80=9Cnoauto=E2=80=9D state in order to prevent it from being = created by a user. I don=E2=80=99t think a new permission is needed to control that = variable, though. The =E2=80=9Csnapshot=E2=80=9D permission implies that =E2=80=9Cmount=E2=80=9D should be allowed as well at least = in the current versions. So it=E2=80=99s redundant. Or, actually, the =E2=80=9Cnoauto=E2=80=9D value for =E2=80=9Csnapdir=E2=80=9D= would eliminate the requirement for =E2=80=9Cmount=E2=80=9D = permissions.=20 I mean: Right now the =E2=80=9Csnapshot=E2=80=9D permission requires = =E2=80=9Cmount=E2=80=9D because the snapshot is mounted upon creation like it or not. If the snapshot was not automatically mounted thanks to = the =E2=80=9Cnoauto=E2=80=9D value for =E2=80=9Csnapdir=E2=80=9D it = would be possible to have a user authorized to manage snapshots but unable to = mount them. Given the very sensible nature of =E2=80=9Cmount=E2=80=9D in Unix it = makes sense.=20 Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003E0B0C-95C5-4D0B-91DB-393877480BDE>