From owner-freebsd-fs@freebsd.org Wed Nov 20 16:58:16 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 A806C1BC22F for ; Wed, 20 Nov 2019 16:58:16 +0000 (UTC) (envelope-from jbe-mlist@magnetkern.de) Received: from sapphire.magnetkern.de (sapphire.magnetkern.de [185.228.139.199]) by mx1.freebsd.org (Postfix) with ESMTP id 47J85g5lZDz447r; Wed, 20 Nov 2019 16:58:15 +0000 (UTC) (envelope-from jbe-mlist@magnetkern.de) Received: from titanium (p57A35420.dip0.t-ipconnect.de [87.163.84.32]) by sapphire.magnetkern.de (Postfix) with ESMTPSA id B0A881FE18; Wed, 20 Nov 2019 16:58:03 +0000 (UTC) Date: Wed, 20 Nov 2019 17:58:03 +0100 From: Jan Behrens To: Borja Marcos Cc: Mike Tancsa , Alan Somers , freebsd-fs Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191120175803.03401c3316fe756cc46f79f1@magnetkern.de> In-Reply-To: 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> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47J85g5lZDz447r X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jbe-mlist@magnetkern.de designates 185.228.139.199 as permitted sender) smtp.mailfrom=jbe-mlist@magnetkern.de X-Spamd-Result: default: False [-0.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; SH_EMAIL_ZRD(0.00)[5.11.0.38]; RECEIVED_SPAMHAUS_PBL(0.00)[32.84.163.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[magnetkern.de]; NEURAL_HAM_LONG(-0.65)[-0.649,0]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[5.11.0.38]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-0.66)[-0.659,0]; IP_SCORE(0.20)[ipnet: 185.228.136.0/22(1.64), asn: 197540(-0.65), country: DE(-0.01)]; 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:197540, ipnet:185.228.136.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Wed, 20 Nov 2019 16:58:16 -0000 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. Regards, Jan