From owner-freebsd-fs@freebsd.org Fri Nov 8 11:52:39 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 BA7381AF8F9 for ; Fri, 8 Nov 2019 11:52:39 +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 478dtZ61pKz4FQ4; Fri, 8 Nov 2019 11:52:38 +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 3869BAB60; Fri, 8 Nov 2019 11:52:27 +0000 (UTC) Date: Fri, 8 Nov 2019 12:52:26 +0100 From: Jan Behrens To: Andriy Gapon Cc: freebsd-fs@freebsd.org Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191108125226.4ffebc252e69c6cfa3c82165@magnetkern.de> In-Reply-To: <46343d6b-b614-2942-a28c-1ba8f28dd5a0@FreeBSD.org> References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <20191107012027.9639f3a9dda1941518358a52@magnetkern.de> <0a823048-d191-72e8-e20b-0491ebd4ea4a@peak.org> <20191107033622.16414272ae743d50f75786ec@magnetkern.de> <46343d6b-b614-2942-a28c-1ba8f28dd5a0@FreeBSD.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 478dtZ61pKz4FQ4 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 [-1.22 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.88)[-0.879,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[magnetkern.de]; NEURAL_HAM_LONG(-0.95)[-0.950,0]; IP_SCORE(0.31)[ipnet: 185.228.136.0/22(2.12), asn: 197540(-0.57), country: DE(-0.01)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[32.84.163.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; 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)[]; FROM_EQ_ENVFROM(0.00)[] 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: Fri, 08 Nov 2019 11:52:39 -0000 On Thu, 7 Nov 2019 08:37:15 +0200 Andriy Gapon wrote: > On 07/11/2019 04:36, Jan Behrens wrote: > > [...] > > > > Not all application fields of snapshots, however, (whether backup or > > replication or other) have the purpose of letting non-privileged users > > access the data. With the current implementation of ZFS I have no > > choice on whether I want this behavior or consider it a security > > problem that should be avoided in my scenario. This also applies to > > snapshots taken for other reasons than (user readable) backups. > > It's an interesting problem. > My take is that snapshots are snapshots and that's how they are. > If you don't like how they work and you actually only need backups, then you can > take backups. E.g., take a snapshot, send it (either full or incremental) to a > backup file in a secure location or to a secure backup system, create a bookmark > for the snapshot -- if you will need future incremental snapshots, destroy the > snapshot. > No snapshots, no .zfs issues :) > > -- > Andriy Gapon That is interesting, I didn't understand the concept of bookmarks before. This would solve the problem of needing to keep snapshots around on the originating server when some data has not been replicated to all destinations yet. It solves the problem of having accidentally readable files sticking around for more than a few seconds if the snapshots (or rather: bookmarks) are created for purposes of replication only. Still, this solution implies either * using snapshots *only* to create bookmarks and deleting them right afterwards, or * dealing with the security issues mentioned in my original post. Of course, "take as is or don't use it" is a valid approach to avoid using insecure software, but I believe adding an option to restrict readability of .zfs/snapdir to the owner of the root would significantly improve security, especially as some operators might not even be aware of the risks. (This issue has been lurking around for years, see the link posted by Mike .) Regards Jan