From owner-freebsd-fs@freebsd.org Fri Nov 8 11:34:41 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 6FE731AF433 for ; Fri, 8 Nov 2019 11:34:41 +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 478dTr3fxtz4DCh for ; Fri, 8 Nov 2019 11:34:40 +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 A20A8AB53; Fri, 8 Nov 2019 11:34:22 +0000 (UTC) Date: Fri, 8 Nov 2019 12:34:21 +0100 From: Jan Behrens To: Peter Eriksson , "Kevin P. Neal" Cc: freebsd-fs@freebsd.org Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191108123421.1974645718e1e7283a4817ee@magnetkern.de> In-Reply-To: References: <20191107004635.c6d2e7d464d3d556a0d87465@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: 478dTr3fxtz4DCh 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.32 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.97)[-0.967,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[magnetkern.de]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.34)[ipnet: 185.228.136.0/22(2.29), asn: 197540(-0.57), country: DE(-0.01)]; 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:34:41 -0000 > > I recently noticed that all ZFS filesystems in FreeBSD allow access to > > the .zfs directory (snapdir) for all users of the system. [...] On Thu, 7 Nov 2019 23:06:24 +0100 Peter Eriksson wrote: > The “easy” solution is to give each user (or group / project) their own ZFS filesystem. Then the “.zfs” directory would be inside the users own $HOME and you can set $HOME to 0700…. > > That is what we are doing. Granted it generates a “few” filesystems (like some 20000 per server (we have around 120k users), and then add hourly snapshots to each as “icing” on the cake). Mounting all those takes a bit of time - but luckily with the latest FreeBSD release things are much faster these days :-) > > There are some other issues with that - like 100% full filesystems causing severe system slowdown during writes… So you really wanna have some monitoring system that warns for that. > > - Peter This would also allow per-user deletion of snapshots, which may come in handy in certain scenarios where making data only accessible by root is not sufficient, such as legal requirements to delete some user's data. However, it (currently) only works in those cases where the root of each filesystem is chmod 700, i.e. where an entire filesystem hierarchy is only readable by a single user. This makes sharing data between users on those filesystems impossible. I'd much prefer the proposal made by "Kevin P. Neal" earlier in this thread, on Thu, 7 Nov 2019 10:19:23 -0500: "Kevin P. Neal" wrote: > On Thu, Nov 07, 2019 at 09:54:11AM -0500, mike tancsa wrote: > > > > Still, it would be a nice feature to have where .zfs could be set to > > root only read.    In a multi user system, my users (me included) do all > > sorts of accidental foot shooting things like making files readable for > > Or only readable to the owner of the top directory in the dataset? As > an option. In cases where users need to access their own snapshots, filesystems for each user can be created. In cases where this is not necessary, i.e. where I just want to make a root-readable backup (or replication snapshot), a single command such as zfs set snapdir=restrict_to_fs_owner /usr/home would suffice. I prefer this a lot over having to create dozens (or hundreds) of filesystems just to fix an issue with access rights. Regards, Jan