From owner-freebsd-fs@freebsd.org Thu Nov 21 11:19:35 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E54631BA051 for ; Thu, 21 Nov 2019 11:19:35 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 47JcXQ6WWfz4F6Z for ; Thu, 21 Nov 2019 11:19:34 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.15.2/8.15.2) with ESMTP id xALBJTfU025282; Thu, 21 Nov 2019 11:19:29 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id xALBJS2u030548; Thu, 21 Nov 2019 11:19:28 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id xALBJSIW030544; Thu, 21 Nov 2019 11:19:28 GMT Date: Thu, 21 Nov 2019 11:19:28 GMT Message-Id: <201911211119.xALBJSIW030544@higson.cam.lispworks.com> From: Martin Simmons To: Jan Behrens CC: borjam@sarenet.es, freebsd-fs@freebsd.org In-reply-to: <20191120175803.03401c3316fe756cc46f79f1@magnetkern.de> (message from Jan Behrens on Wed, 20 Nov 2019 17:58:03 +0100) Subject: Re: ZFS snapdir readability (Crosspost) References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <9B22AD46-BE87-4305-9638-74D23AD4C8CA@sarenet.es> <261FE331-EC5C-48C8-9249-9BCBF887CE38@sarenet.es> <913f7040-6e38-452d-6187-e17fae63b652@sentex.net> <20191120144041.7f916360dc0c69bf509c9bd1@magnetkern.de> <20191120163437.691abd369ab9c0a6d7d45ff2@magnetkern.de> <20191120175803.03401c3316fe756cc46f79f1@magnetkern.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47JcXQ6WWfz4F6Z X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of martin@lispworks.com has no SPF policy when checking 46.17.166.21) smtp.mailfrom=martin@lispworks.com X-Spamd-Result: default: False [-0.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.53)[-0.533,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[5.11.0.38]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lispworks.com]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.83)[-0.830,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[21.166.17.46.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:51055, ipnet:46.17.166.0/24, country:GB]; IP_SCORE(-0.02)[country: GB(-0.08)]; SH_EMAIL_ZRD(0.00)[5.11.0.38] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 11:19:36 -0000 >>>>> On Wed, 20 Nov 2019 17:58:03 +0100, Jan Behrens said: > > On Wed, 20 Nov 2019 17:07:44 +0100 > Borja Marcos wrote: > > > > On 20 Nov 2019, at 16:34, Jan Behrens 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