From owner-freebsd-fs@freebsd.org Wed Aug 16 10:19:38 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6E95DD23B1 for ; Wed, 16 Aug 2017 10:19:38 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8911F7CE92 for ; Wed, 16 Aug 2017 10:19:37 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.54] (unknown [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPA id DF53E9DC48A; Wed, 16 Aug 2017 12:12:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: protecting zfs snapshot info From: Borja Marcos In-Reply-To: Date: Wed, 16 Aug 2017 12:12:18 +0200 Cc: "freebsd-fs@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <003E0B0C-95C5-4D0B-91DB-393877480BDE@sarenet.es> References: <52984307-2C6C-454C-A69B-15FB4AE01E1B@sarenet.es> <5e3145ab-246a-f213-80b0-000dd801fbef@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 10:19:38 -0000 > On 15 Aug 2017, at 14:20, Mike Tancsa 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 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.