From owner-freebsd-fs@freebsd.org Wed Nov 6 23:46:54 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 96EA117C2F0 for ; Wed, 6 Nov 2019 23:46:54 +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 477jqd2r0dz3JXH for ; Wed, 6 Nov 2019 23:46:53 +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 E25ECA9AE for ; Wed, 6 Nov 2019 23:46:35 +0000 (UTC) Date: Thu, 7 Nov 2019 00:46:35 +0100 From: Jan Behrens To: freebsd-fs@freebsd.org Subject: ZFS snapdir readability (Crosspost) Message-Id: <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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 477jqd2r0dz3JXH 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.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; DMARC_NA(0.00)[magnetkern.de]; MV_CASE(0.50)[]; IP_SCORE(-0.12)[asn: 197540(-0.59), 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: Wed, 06 Nov 2019 23:46:54 -0000 Dear all, I'd like to crosspost an issue I have with the .zfs/snapdir directory. My original post was in freebsd-questions@freebsd.org but apparently nobody could answer my questions there. Since the topic is quite ZFS specific, I wonder if this is the better place to ask my questions. Original subject: ZFS snapdir readability - feature request or security issue? Original date: Sun, 27 Oct 2019 12:27:28 +0100 Dear all, I recently noticed that all ZFS filesystems in FreeBSD allow access to the .zfs directory (snapdir) for all users of the system. It is possible to hide that directory using the snapdir option: snapdir=hidden | visible Controls whether the .zfs directory is hidden or visible in the root of the file system as discussed in the "Snapshots" section. The default value is hidden. However, setting snapdir=hidden will only "hide" the directory from "ls". It is still possible to access that directory, also as a non-privileged user! It seems to be impossible to restrict access to this directory. Calling chmod 700 /.zfs results in "chmod: /.zfs: Operation not supported". Given the immutability of snapshots, the directories and files will have access rights from the point in time when the snapshot was taken. Considering a system that creates snapshots regularly (e.g. for backup or replication purposes), this could lead to security issues, as I would like to illustrate with the following example: Consider a user (Alice) who accidentally created a file /usr/home/alice/.ssh/id_rsa as publicly readible, but who notices shortly after that this was a mistake. Alice fixes her mistake by calling: chmod 600 /usr/home/alice/.ssh/id_rsa If in the meantime a snapshot zroot/usr/home@2019-10-27 was taken, which is intended to be kept for a longer time, then Bob will be able to access Alice's private SSH key through the file /usr/home/.zfs/snapshot/2010-10-27/alice/.ssh/id_rsa As far as I understand, there is no (clean) way to prohibit this, except deleting the whole snapshot (which might not be desirable in all scenarios). Note that: su - root chmod 700 /usr/home/.zfs => Operation not supported chmod 700 /usr/home/.zfs/snapshot => Operation not supported chmod 700 /usr/home/.zfs/snapshot/2019-10-27 => Read-only file system Of course, one could argue that Alice shouldn't have made the mistake in the first place. Nonetheless, I consider it to be a security issue if regular snapshots cause files which were once publicly readable to be always readable (as long as certain snapshots exist). Moreover, a user might want to deliberatly block access to a file that was intendedly public before. One (dirty) workaround I was able to figure out is to do a mount_nullfs /var/empty /usr/home/.zfs which results in the following behavior: - /usr/home/.zfs is still hidden - /usr/home/.zfs is empty for all users (root and non-privileged users) I was able to improve this by doing: mkdir -p /usr/home/protected/snapshot chmod 700 /usr/home/protected mount_nullfs /usr/home/.zfs/snapshot /usr/home/protected/snapshot mount_nullfs /var/empty /usr/home/.zfs This way, the root user can access the snapshot directory through /usr/home/protected/snapshot while all other users should (hopefully) not be able to gain access to snapshot data. This workaround, however, has several drawbacks: - Considering a larger number of ZFS filesystems on an average system (my system came with 14 file systems by default), this will bloat the output of "mount" and easily cause confusion. - There can be race conditions when mounting a previously unmounted ZFS filesystem, such that for a small moment (after mounting the ZFS file system and before doing the nullfs mount), a malicious user could access the hidden .zfs directory. - Using the default commands, it is likely to accidentally forget the nullfs mount and leave the snapdir exposed to non-privileged users. Is there any other method to prohibit non-privileged users from accessing the ZFS snapdir? If not, I would propose to add one. I'm not even sure if this is a feature request or rather fixing a security vulnerability as explained in the Alice & Bob example above. Kind regards, Jan Behrens From owner-freebsd-fs@freebsd.org Thu Nov 7 00:02:28 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 F32C617CBC4 for ; Thu, 7 Nov 2019 00:02:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 477k9b5Rk0z3KCN for ; Thu, 7 Nov 2019 00:02:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id b16so394447otk.9 for ; Wed, 06 Nov 2019 16:02:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=irX95Jo4NSrWLR+55DCo8/zDVMQSFd9KxtaNp2Vp81E=; b=dvAMSR3u/oVlS5qgsuxHlHqEtrWjJXm8rxS64FNQS9rKKzRW0U5sl0oj2qrTsjQk5J TuYhm3EVZeJb8fZBhlBYcc9cW5jxJBJMdBS1+ZaqecHVrHBNlWIomCTh5SIJiweEIaoK Y+bMkgUPl68Ekg1Fvi/Klh7W6obEIwt3+8q0Flb+0nn2idulZFPWySk8NiN+ORc1wKN8 hh2PgwN4qaSwKkPEV8Cf/TLGBYCt3h+Wh8KXcMN2MumWEj0YrArYiffGrOy1O0sZDLCS yyK543EUaWSpgpAbWaNOOQCncpcikjon6Kg4rM7Smbx4k5ZYhQH8MVlQ2F5T5DQ6XRfN f5gw== X-Gm-Message-State: APjAAAUkH9roaSP5xV08KPADmRG6fJbhbaZ2KfRsI2LrqE8jfEkARq4O ySngzuuDprfy/0L9iG0UGTnyaJlvdx0rgOryLPmsJFhQ X-Google-Smtp-Source: APXvYqzUrjNnAVirmf0wxFEAV+5h4SxAtLaPqtwMNgrTSzDn0/8be7/OnR50drKyrMQhEQqNdrLcwaUs4XonSSGWGoc= X-Received: by 2002:a05:6830:4a1:: with SMTP id l1mr330165otd.291.1573084946221; Wed, 06 Nov 2019 16:02:26 -0800 (PST) MIME-Version: 1.0 References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> In-Reply-To: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> From: Alan Somers Date: Wed, 6 Nov 2019 17:02:14 -0700 Message-ID: Subject: Re: ZFS snapdir readability (Crosspost) To: Jan Behrens Cc: freebsd-fs X-Rspamd-Queue-Id: 477k9b5Rk0z3KCN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.44 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.13 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[44.210.85.209.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[44.210.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.13)[ip: (-0.39), ipnet: 209.85.128.0/17(-3.21), asn: 15169(-2.01), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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, 07 Nov 2019 00:02:29 -0000 On Wed, Nov 6, 2019 at 4:46 PM Jan Behrens wrote: > Dear all, > > I'd like to crosspost an issue I have with the .zfs/snapdir directory. > My original post was in freebsd-questions@freebsd.org but apparently > nobody could answer my questions there. Since the topic is quite ZFS > specific, I wonder if this is the better place to ask my questions. > > Original subject: > ZFS snapdir readability - feature request or security issue? > > Original date: Sun, 27 Oct 2019 12:27:28 +0100 > > Dear all, > > I recently noticed that all ZFS filesystems in FreeBSD allow access to > the .zfs directory (snapdir) for all users of the system. It is > possible to hide that directory using the snapdir option: > > snapdir=hidden | visible > Controls whether the .zfs directory is hidden or visible in the root > of the file system as discussed in the "Snapshots" section. The > default value is hidden. > > However, setting snapdir=hidden will only "hide" the directory from > "ls". It is still possible to access that directory, also as a > non-privileged user! > > It seems to be impossible to restrict access to this directory. Calling > chmod 700 /.zfs results in "chmod: /.zfs: Operation not supported". > > Given the immutability of snapshots, the directories and files will > have access rights from the point in time when the snapshot was taken. > Considering a system that creates snapshots regularly (e.g. for backup > or replication purposes), this could lead to security issues, as I > would like to illustrate with the following example: > > Consider a user (Alice) who accidentally created a file > /usr/home/alice/.ssh/id_rsa as publicly readible, but who notices > shortly after that this was a mistake. Alice fixes her mistake by > calling: chmod 600 /usr/home/alice/.ssh/id_rsa > > If in the meantime a snapshot zroot/usr/home@2019-10-27 was taken, > which is intended to be kept for a longer time, then Bob will be able > to access Alice's private SSH key through the > file /usr/home/.zfs/snapshot/2010-10-27/alice/.ssh/id_rsa > > As far as I understand, there is no (clean) way to prohibit this, except > deleting the whole snapshot (which might not be desirable in all > scenarios). Note that: > > su - root > chmod 700 /usr/home/.zfs => Operation not supported > chmod 700 /usr/home/.zfs/snapshot => Operation not supported > chmod 700 /usr/home/.zfs/snapshot/2019-10-27 => Read-only file system > > Of course, one could argue that Alice shouldn't have made the mistake > in the first place. Nonetheless, I consider it to be a security issue > if regular snapshots cause files which were once publicly readable to > be always readable (as long as certain snapshots exist). Moreover, a > user might want to deliberatly block access to a file that was > intendedly public before. > > One (dirty) workaround I was able to figure out is to do a > mount_nullfs /var/empty /usr/home/.zfs which results in the following > behavior: > - /usr/home/.zfs is still hidden > - /usr/home/.zfs is empty for all users (root and non-privileged users) > > I was able to improve this by doing: > mkdir -p /usr/home/protected/snapshot > chmod 700 /usr/home/protected > mount_nullfs /usr/home/.zfs/snapshot /usr/home/protected/snapshot > mount_nullfs /var/empty /usr/home/.zfs > > This way, the root user can access the snapshot directory > through /usr/home/protected/snapshot while all other users should > (hopefully) not be able to gain access to snapshot data. This > workaround, however, has several drawbacks: > > - Considering a larger number of ZFS filesystems on an average system > (my system came with 14 file systems by default), this will bloat the > output of "mount" and easily cause confusion. > - There can be race conditions when mounting a previously unmounted ZFS > filesystem, such that for a small moment (after mounting the ZFS file > system and before doing the nullfs mount), a malicious user could > access the hidden .zfs directory. > - Using the default commands, it is likely to accidentally forget the > nullfs mount and leave the snapdir exposed to non-privileged users. > > Is there any other method to prohibit non-privileged users from > accessing the ZFS snapdir? If not, I would propose to add one. I'm not > even sure if this is a feature request or rather fixing a security > vulnerability as explained in the Alice & Bob example above. > > > Kind regards, > Jan Behrens > Your analysis of the snapdir is correct. Setting it to hidden doesn't make it inaccessible. That's not unique to FreeBSD, however. I believe it's common to all ZFS implementations (I just double checked on Oracle Solaris). Also, the problem isn't unique to ZFS. Any backup system would have the same problem, as long as users are allowed to access the backups directly. And in fact, Bob could've directly observed Alice's id_rsa file before she changed it. So I don't think this should be considered a security vulnerability. The best course for Alice would be to consider her id_rsa as compromised as soon as she notices the problem, and delete it. -Alan From owner-freebsd-fs@freebsd.org Thu Nov 7 00:20:38 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 D69EC17D95A for ; Thu, 7 Nov 2019 00:20:38 +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 477kZZ5KBPz3LcS; Thu, 7 Nov 2019 00:20: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 CCE72A9D4; Thu, 7 Nov 2019 00:20:27 +0000 (UTC) Date: Thu, 7 Nov 2019 01:20:27 +0100 From: Jan Behrens To: freebsd-fs@freebsd.org Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191107012027.9639f3a9dda1941518358a52@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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 477kZZ5KBPz3LcS X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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, 07 Nov 2019 00:20:38 -0000 > On Wed, Nov 6, 2019 at 4:46 PM Jan Behrens wrote: > > > I recently noticed that all ZFS filesystems in FreeBSD allow access to > > the .zfs directory (snapdir) for all users of the system. On Wed, 6 Nov 2019 17:02:14 -0700 Alan Somers wrote: > Your analysis of the snapdir is correct. Setting it to hidden doesn't make > it inaccessible. That's not unique to FreeBSD, however. I believe it's > common to all ZFS implementations (I just double checked on Oracle > Solaris). I already suspected that this might be an issue originating from ZFS itself (and not be FreeBSD specific). Thank you for the research (I don't have a Solaris system at hand ;-) > Also, the problem isn't unique to ZFS. Any backup system would > have the same problem, as long as users are allowed to access the backups > directly. My problem here is that with most (or maybe even all) other backup systems, I would be able to restrict ordinary users from accessing all backups. So I consider this problem to be pretty much unique to ZFS (unless I misunderstood your point?) > And in fact, Bob could've directly observed Alice's id_rsa file > before she changed it. So I don't think this should be considered a > security vulnerability. The best course for Alice would be to consider her > id_rsa as compromised as soon as she notices the problem, and delete it. > > -Alan I already foresaw this argument and mentioned a possible counter-argument: > > Of course, one could argue that Alice shouldn't have made the mistake > > in the first place. Nonetheless, I consider it to be a security issue > > if regular snapshots cause files which were once publicly readable to > > be always readable (as long as certain snapshots exist). Moreover, a > > user might want to deliberatly block access to a file that was > > intendedly public before. There could be several examples (other than an ssh key file) where someone wants to restrict access to a previously publicly readable file (whether it was deliberately publicly readable or accidentally publicly readable). Regards Jan From owner-freebsd-fs@freebsd.org Thu Nov 7 00:36:18 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 6B25717E21B for ; Thu, 7 Nov 2019 00:36:18 +0000 (UTC) (envelope-from alan@peak.org) Received: from filter02.peak.org (filter02.peak.org [207.55.16.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 477kwd3GpMz3Mbc for ; Thu, 7 Nov 2019 00:36:16 +0000 (UTC) (envelope-from alan@peak.org) Received: from zmail-mta02.peak.org ([207.55.16.112]) by filter02.peak.org ({c0e096ac-ab76-477d-8a9d-eab3e47a6d30}) via TCP (outbound) with ESMTPS id 20191107003613941_0000 for ; Wed, 06 Nov 2019 16:36:13 -0800 X-RC-FROM: X-RC-RCPT: Received: from localhost (localhost [127.0.0.1]) by zmail-mta02.peak.org (Postfix) with ESMTP id C0942115F3D for ; Wed, 6 Nov 2019 16:36:12 -0800 (PST) Received: from zmail-mta02.peak.org ([127.0.0.1]) by localhost (zmail-mta02.peak.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jpJZ2Jri5uGg for ; Wed, 6 Nov 2019 16:36:12 -0800 (PST) Received: from mailproxy-lb-02.peak.org (mailproxy-lb-02.peak.org [207.55.17.92]) by zmail-mta02.peak.org (Postfix) with ESMTP id AE8844C503 for ; Wed, 6 Nov 2019 16:36:12 -0800 (PST) Subject: Re: ZFS snapdir readability (Crosspost) To: freebsd-fs@freebsd.org References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <20191107012027.9639f3a9dda1941518358a52@magnetkern.de> From: Alan Batie Message-ID: <0a823048-d191-72e8-e20b-0491ebd4ea4a@peak.org> Date: Wed, 6 Nov 2019 16:36:08 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20191107012027.9639f3a9dda1941518358a52@magnetkern.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030101000101050209070508" X-MAG-OUTBOUND: peakinternet.redcondor.net@207.55.16/22 X-Rspamd-Queue-Id: 477kwd3GpMz3Mbc X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=peak.org; spf=pass (mx1.freebsd.org: domain of alan@peak.org designates 207.55.16.93 as permitted sender) smtp.mailfrom=alan@peak.org X-Spamd-Result: default: False [-5.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_DN_NONE(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[peak.org,none]; IP_SCORE(-0.00)[asn: 13868(0.03), country: US(-0.05)]; RCVD_IN_DNSWL_LOW(-0.10)[93.16.55.207.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:13868, ipnet:207.55.0.0/17, country:US]; 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: Thu, 07 Nov 2019 00:36:18 -0000 This is a cryptographically signed message in MIME format. --------------ms030101000101050209070508 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/6/19 4:20 PM, Jan Behrens wrote: > My problem here is that with most (or maybe even all) other backup > systems, I would be able to restrict ordinary users from accessing all > backups. So I consider this problem to be pretty much unique to ZFS This is going to be a problem with any system that does snapshots - our Netapps would also have the same issue, and it's unfortunate, but one you want as you want users to be able to recover their files on their own, it's part of the point... --------------ms030101000101050209070508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CxMwggUlMIIEDaADAgECAhA4Yf2XOFoXFgZP1xmDoohgMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODEyMTAwMDAw MDBaFw0xOTEyMTAyMzU5NTlaMB4xHDAaBgkqhkiG9w0BCQEWDWFsYW5AcGVhay5vcmcwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDrE3MDy9uMqdWAcxGbzMvMJUDM+HT0Gn2z uyjae+ykG10POv5x1E+HvjLcVXEGNylxBS8rHIxwC2mSUtZ0CXtKLaNIqeubnlDcQcmOimdB OR1EXBDGFTE17YPwRVLT/zW2BW2Foa9hROUSuOIt7K0hadI5NVK2otG3ThsVAna3bGive8DE 0AsPM86tLiyGnZhwHCyYtwyHVuxTyWiGd47zKAfb7zFEoTKAP4ajqvQI2sZjpFLsTkGN0wsZ SYOcn0/VazNYDhvGMq7DQiZEuQ056GSLww6lpNIm1MNFScgXrz0MYyGSg0mTN++EAG/N6cov G6pr9tujjZjbG0hP7NK1AgMBAAGjggHjMIIB3zAfBgNVHSMEGDAWgBSCr2yM+MX+lmF86B89 K3FIXsSLwDAdBgNVHQ4EFgQUX89/i2l4sBunc4qvzOtkOPUgEAswDgYDVR0PAQH/BAQDAgWg MAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCG SAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRw Oi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAYBgNV HREEETAPgQ1hbGFuQHBlYWsub3JnMA0GCSqGSIb3DQEBCwUAA4IBAQA6WiF45lppCuiVuIDx 4QyN3PQCvpQMFTMpXXWLpJCYNH7Z9DvNhGTWnCbPswfYcMzReMc68AaM8HprzgmkrJmsyqb4 Bl8CPoevCZKPhoQa7gyU4DWDdYPpoZBN5n2iyENJUQrbo4NYFXOAkqOs9em1pwqoELZlWdzm zXG5BAUQG6RMBOdVPsOMzBuE4jufULT9S/RrPPR4ClKkg2rMESfHREWH8b5YQe5Lz0BAOAM4 B1XUQuH5Lz+9g0zODnZij/2QPtVA1tB0WyhFiCe2HXNWW44NSQYOE3DC1n+7LHOmoxWEw0Mn KYjgojzKNRycDTmPhT47gNhiNxExBi6SkF0kMIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZ uKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMw MTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu ZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55X rCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFL IP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9a U/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BO rNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9tGKTDyUGg2hJZjrqck39UIm/nKbpD SZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK+xS1AgMBAAGjggE8MIIBODAfBgNV HSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4EFgQUgq9sjPjF/pZhfOgfPStx SF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAG BgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEBBGUwYzA7BggrBgEF BQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRkVHJ1c3RDQS5jcnQw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkqhkiG9w0BAQwFAAOC AgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZr rm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51 csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3n jeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrM IzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08Q JNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1 Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4U Ju1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12 TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0 WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ1MIIEMQIBATCBrDCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDhh/Zc4WhcWBk/XGYOiiGAw DQYJYIZIAWUDBAIBBQCgggJZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE5MTEwNzAwMzYwOFowLwYJKoZIhvcNAQkEMSIEIEKdxnvbnzElmlbXJVv9magl tf8fBzoHkvH6z+465CnKMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwgb0GCSsGAQQBgjcQBDGBrzCBrDCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDhh/Zc4WhcWBk/XGYOiiGAwgb8GCyqG SIb3DQEJEAILMYGvoIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQQIQOGH9lzhaFxYGT9cZg6KIYDANBgkqhkiG9w0BAQEFAASCAQBkLHlWLwueIm9q biIxGR5OOyJozrIpbQ6UEKa6qJpolxvCwKpaJAiX3FPu+7hwpgF9PIfJYxaujvpQBroOJ36c WYkvX8pkZOl763ei1f0MIp/73SpL1NmE4UrrOAOsAaS32WpRRa4pnCj6Cu/455swjvIz7WJG J5PsrLntKcsZZHCCqPXn8D4249bk/QEcQaaykKeo/6INN/zAJ2PRXC47JyCxbKpY+FoJThbi 3wjgZy5lskaJfZ5mokBNxYb1hL4iUncSZ7MFNVzhcb8WPoaJMSXTk3gqkbv+BEevg3VwrtcE bE3rLOVpEfbWMOvWNARuGsetiLSl7a6hnFjgz6i2AAAAAAAA --------------ms030101000101050209070508-- From owner-freebsd-fs@freebsd.org Thu Nov 7 02:36:36 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 1E7F61A436A for ; Thu, 7 Nov 2019 02:36:36 +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 477nbR1YYVz40YN for ; Thu, 7 Nov 2019 02:36:34 +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 511C9A9F6 for ; Thu, 7 Nov 2019 02:36:23 +0000 (UTC) Date: Thu, 7 Nov 2019 03:36:22 +0100 From: Jan Behrens To: freebsd-fs@freebsd.org Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191107033622.16414272ae743d50f75786ec@magnetkern.de> In-Reply-To: <0a823048-d191-72e8-e20b-0491ebd4ea4a@peak.org> References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <20191107012027.9639f3a9dda1941518358a52@magnetkern.de> <0a823048-d191-72e8-e20b-0491ebd4ea4a@peak.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: 477nbR1YYVz40YN 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.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; DMARC_NA(0.00)[magnetkern.de]; MV_CASE(0.50)[]; IP_SCORE(-0.12)[asn: 197540(-0.58), 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: Thu, 07 Nov 2019 02:36:36 -0000 On Wed, 6 Nov 2019 16:36:08 -0800 Alan Batie wrote: > On 11/6/19 4:20 PM, Jan Behrens wrote: > > > My problem here is that with most (or maybe even all) other backup > > systems, I would be able to restrict ordinary users from accessing all > > backups. So I consider this problem to be pretty much unique to ZFS > > This is going to be a problem with any system that does snapshots - our > Netapps would also have the same issue, and it's unfortunate, but one > you want as you want users to be able to recover their files on their > own, it's part of the point... I understand the point now. 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. Regards, Jan From owner-freebsd-fs@freebsd.org Thu Nov 7 14:54:13 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 09B631B68DF for ; Thu, 7 Nov 2019 14:54:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (unknown [IPv6:2607:f3e0:0:3::19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "pyroxene2.sentex.ca", Issuer "pyroxene2.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4785yX6Dswz3Hd1; Thu, 7 Nov 2019 14:54:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:a10d:ac5a:ce6d:7222] ([IPv6:2607:f3e0:0:4:a10d:ac5a:ce6d:7222]) by pyroxene2a.sentex.ca (8.15.2/8.15.2) with ESMTPS id xA7EsBSb072038 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Nov 2019 09:54:11 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: ZFS snapdir readability (Crosspost) To: Alan Somers , Jan Behrens Cc: freebsd-fs References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> From: mike tancsa Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; keydata= mQENBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAG0HW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+iQFUBBMBCAA+FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAlywzOYCGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ eVOEFl5WrMhnPAf7Bf+ola0V9t4i8rwCMGvzkssGaxY/5zNSZO9BgSgfN0WzgmBEOy/3R4km Yn5KH94NltJYAAE5hqkFmAwK6psOqAR9cxHrRfU+gV2KO8pCDc6K/htkQcd/mclJYpCHp6Eq EVJOiAxcNaYuHZkeMdXDuvvI5Rk82VHk84BGgxIqIrhLlkguoPbXOOa+8c/Mpb1sRAGZEOuX EzKNC49+GS9gKW6ISbanyPsGEcFyP7GKMzcHBPf3cPrewZQZ6gBoNscasL6IJeAQDqzQAxbU GjO0qBSMRgnLXK7+DJlxrYdHGXqNbV6AYsmHJ6c2WWWiuRviFBqXinlgJ2FnYebZPAfWibkB DQRcsMzkAQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4 axtKRSG1t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1 qzAJweEtRdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6c Lm0EiHPOl5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5 o9KKu4O7gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQAB iQE8BBgBCAAmFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAlywzOQCGwwFCQHhM4AACgkQeVOE Fl5WrMhmjQf/dBCjAVn1J0GzSsHiLvSAQz1cchbdy8LD0Tnpzjgp5KLU7sNojbI8vqt4yKAi cayI88j8+xxNXPMWM4pHELuUuVHS5XTpHa/wwulUtI5w/zyKlUDsIvqTPZLUEwH7DfNBueVM WyNaIjV2kxSmM8rNMC+RkgyfbjGLCkmWsMRVuLIUYpl5D9WHmenUbiErlKU2KvEEXEg/aLKq 3m/AdM9RAYsP9O4l+sAZEfyYoNJzDhTZMzn/9Q0uFPLK9smDQh4WBTFaApveVJPHRKmHPoNF Xxj+yScYdQ4SKH34WnhNSELvnZQ3ulH5tpASmm0w+GxfZqSc8+QCwoKtBRDUxoE56A== Message-ID: Date: Thu, 7 Nov 2019 09:54:11 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4785yX6Dswz3Hd1 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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, 07 Nov 2019 14:54:13 -0000 On 11/6/2019 7:02 PM, Alan Somers wrote: > > Your analysis of the snapdir is correct. Setting it to hidden doesn't make > it inaccessible. That's not unique to FreeBSD, however. I believe it's > common to all ZFS implementations (I just double checked on Oracle > Solaris). Also, the problem isn't unique to ZFS. Any backup system would > have the same problem, as long as users are allowed to access the backups > directly. And in fact, Bob could've directly observed Alice's id_rsa file > before she changed it. So I don't think this should be considered a > security vulnerability. The best course for Alice would be to consider her > id_rsa as compromised as soon as she notices the problem, and delete it. 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 a brief period of time they should not make readable.  I think I recall ZoL adding this as a feature back when I ran into this issue via zfs allow / unallow ? Or at least I think I saw discussion about it. https://github.com/zfsonlinux/zfs/issues/3963     ---Mike From owner-freebsd-fs@freebsd.org Thu Nov 7 18:07: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 4CC2D1BB849 for ; Thu, 7 Nov 2019 18:07:35 +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 478BFf1bpVz43W5 for ; Thu, 7 Nov 2019 18:07:33 +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 AF07CAA7D for ; Thu, 7 Nov 2019 18:07:21 +0000 (UTC) Date: Thu, 7 Nov 2019 19:07:20 +0100 From: Jan Behrens To: freebsd-fs@freebsd.org Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191107190720.8ed2e1016b02c14ef5071adf@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: 478BFf1bpVz43W5 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.84 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.94)[-0.937,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.58)[-0.582,0]; DMARC_NA(0.00)[magnetkern.de]; MV_CASE(0.50)[]; IP_SCORE(0.38)[ipnet: 185.228.136.0/22(2.48), asn: 197540(-0.58), 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: Thu, 07 Nov 2019 18:07:35 -0000 On Thu, 7 Nov 2019 09:54:11 -0500 mike tancsa wrote: > [...] I think I recall > ZoL adding this as a feature back when I ran into this issue via zfs > allow / unallow ? Or at least I think I saw discussion about it. > > https://github.com/zfsonlinux/zfs/issues/3963 > >     ---Mike I'm happy that apparently some other people share my worries, like "jelinekr" commented already on Oct 27, 2015 on that ticket: "We need this for security reasons in cases where a too permissive dirent entry gets fixed, the vulnerability is still present and accessible in older snapshots." The ticket is marked as closed, but this seems to be a mistake. I found out about the "snapdir" property for "zfs allow" a while ago. Using "zfs allow snapdir ", however, does *not* grant access to access the .zfs directory, and "zfs unallow snapdir " does not revoke reading privileges. Instead, "zfs allow" can be used to grant non-privileged users the right to set the snapdir property to "visible" or "hidden" as follows: root # zfs allow bob snapdir zroot/usr/home root # su bob bob % zfs set snapdir=visible zroot/usr/home bob % zfs set snapdir=hidden zroot/usr/home bob % exit root # zfs unallow bob snapdir zroot/usr/home root # su bob bob % zfs set snapdir=visible zroot/usr/home cannot set property for 'zroot': permission denied bob % cat /usr/home/.zfs/snapshot/2010-10-27/alice/.ssh/id_rsa -----BEGIN OPENSSH PRIVATE KEY----- ... I assume that there was a misunderstanding when closing the ticket referenced above, since implementing "zfs allow" does not fix the issue (unless Linux' "zfs allow" works differently than FreeBSD's). See also comment by wl2018 on Feb 1, 2018 on https://github.com/zfsonlinux/zfs/issues/3963 Regards, Jan From owner-freebsd-fs@freebsd.org Thu Nov 7 22:06:31 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 0482417BBDA for ; Thu, 7 Nov 2019 22:06:31 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 478HYK00rQz4Rjm for ; Thu, 7 Nov 2019 22:06:28 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 65BAA40013; Thu, 7 Nov 2019 23:06:24 +0100 (CET) Received: from [192.168.1.132] (h-201-140.A785.priv.bahnhof.se [98.128.201.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 2DA1240011; Thu, 7 Nov 2019 23:06:23 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: ZFS snapdir readability (Crosspost) From: Peter Eriksson In-Reply-To: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> Date: Thu, 7 Nov 2019 23:06:24 +0100 Cc: freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> To: Jan Behrens X-Mailer: Apple Mail (2.3601.0.10) X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 478HYK00rQz4Rjm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=liu.se; spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 130.236.254.3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[3.254.236.130.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[liu.se,none]; IP_SCORE(-0.01)[country: SE(-0.03)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2843, ipnet:130.236.0.0/16, country:SE]; MID_RHS_MATCH_FROM(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: Thu, 07 Nov 2019 22:06:31 -0000 The =E2=80=9Ceasy=E2=80=9D solution is to give each user (or group / = project) their own ZFS filesystem. Then the =E2=80=9C.zfs=E2=80=9D = directory would be inside the users own $HOME and you can set $=08HOME = to 0700=E2=80=A6. That is what we are doing. Granted it generates a =E2=80=9Cfew=E2=80=9D = filesystems (like some 20000 per server (we have around 120k users), and = then add hourly snapshots to each as =E2=80=9Cicing=E2=80=9D 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=E2=80=A6 So you really = wanna have some monitoring system that warns for that. - Peter >=20 > I recently noticed that all ZFS filesystems in FreeBSD allow access to > the .zfs directory (snapdir) for all users of the system. It is > possible to hide that directory using the snapdir option: From owner-freebsd-fs@freebsd.org Fri Nov 8 00:31:37 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 768AF1A128B for ; Fri, 8 Nov 2019 00:31:37 +0000 (UTC) (envelope-from bsdunix44@gmail.com) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 478Lmm3nhmz4csK for ; Fri, 8 Nov 2019 00:31:35 +0000 (UTC) (envelope-from bsdunix44@gmail.com) Received: by mail-ot1-x335.google.com with SMTP id 94so3709441oty.8 for ; Thu, 07 Nov 2019 16:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:subject:mime-version:to:from:in-reply-to :cc:date:message-id:references; bh=dHR52VmTAIWT2pDI6YVdhAjcMat4EONZfe9B94H/No4=; b=vCTd0I4KfbjgXihaqg0GqAsMdOZ+hHiQf5rBoMotUFdokUn8GwQLoKAZoTmjSau+v3 wHGqsIqqX17GHoREPvZDfx84S1xdrpRBqk8xfKktvO3BheldanWCuPEqQwYwgPa0/X1w D3rLXV8iUqwNBofRNWDioaZSNgGwgSjyyfa3fR732CGFoyWcErXnzpVgwPTm+I22NOv/ IX6/fBAfv1h+aejfqbjJAyayYp54E+IPCd5clR6xApCIped6en7CZsl9jpfHZXEhUPRy KYY91KaPMCb14H3tidsCpStzLYoFxgxEvAk9Ca4QlCYuYqd4i46v33iFpArSxl0Ho/pW MhtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:subject:mime-version :to:from:in-reply-to:cc:date:message-id:references; bh=dHR52VmTAIWT2pDI6YVdhAjcMat4EONZfe9B94H/No4=; b=k32jmfjdQdXBHUYTFfvH05nqhr5jvPoxRJZv/vN7EkRv4ljNcjzLYXxLYASsd6UOjx c3b17IvfskvBpZYtFkaRtURfb8oA+BnDNVXfQcmKcni8OKCKZmrwHRx1qpvsp14U23rp 4dfI7T+JKCFPesoHUaZU48GEyRezmMdoYuNJne3W7uiI0KKLf1kx8tFnSBcd3FCn5Ukr Dz/n/PUlFJlOOPnqHgpH9YkpXqU0/EHiqBaIx8QwUs08lOdlW1IC1sc70mEHLTzIh0QD bort61zdUwjD3J61Gqw2ZZ+i7bbTgXGaOzRsUteM1Qa7WIWt47VqO3LfJJG+3wqgpi63 V5Pw== X-Gm-Message-State: APjAAAWVqm8DHE8f0LGMYEfPzOkSwOMtvNKFi3IuzPuulzY3a0+N/nRk GAAgnXjtazAxy8L6iVhSL1s/6PwesXw= X-Google-Smtp-Source: APXvYqyV6N9DEXRYHo8O0zcve4BKiaB40d5YO/qrWgs3JOYm2uDw2ATK5VbRzJlyJV0AJ+M12JIMhQ== X-Received: by 2002:a05:6830:1b68:: with SMTP id d8mr5839445ote.203.1573173094286; Thu, 07 Nov 2019 16:31:34 -0800 (PST) Received: from ?IPv6:2605:a601:ae5d:8b00:38b3:8142:1d4f:bed? ([2605:a601:ae5d:8b00:38b3:8142:1d4f:bed]) by smtp.gmail.com with ESMTPSA id m4sm1308572otf.0.2019.11.07.16.31.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Nov 2019 16:31:32 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: ZFS snapdir readability (Crosspost) Mime-Version: 1.0 (1.0) To: Peter Eriksson X-Universally-Unique-Identifier: FCA5DB61-3C50-4FD7-8883-FFA3AEAB362C From: Chris Watson In-Reply-To: Cc: Jan Behrens , freebsd-fs@freebsd.org Date: Thu, 7 Nov 2019 18:31:31 -0600 X-Apple-Message-Smime-Encrypt: NO Message-Id: <65AE896D-A32E-451A-B9D0-EC40D438BB03@gmail.com> References: X-Apple-Notify-Thread: NO X-Mailer: iPhone Mail (17A878) X-Rspamd-Queue-Id: 478Lmm3nhmz4csK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=vCTd0I4K; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bsdunix44@gmail.com designates 2607:f8b0:4864:20::335 as permitted sender) smtp.mailfrom=bsdunix44@gmail.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-7.37), ipnet: 2607:f8b0::/32(-2.35), asn: 15169(-2.01), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[5.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(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 00:31:37 -0000 Peter, on your last point about 100% utilization, don=E2=80=99t you use quot= as/user quotas to prevent that? Chris Sent from my iPhone > On Nov 7, 2019, at 4:06 PM, Peter Eriksson wrote: >=20 > =EF=BB=BFThe =E2=80=9Ceasy=E2=80=9D solution is to give each user (or grou= p / project) their own ZFS filesystem. Then the =E2=80=9C.zfs=E2=80=9D direc= tory would be inside the users own $HOME and you can set $=08HOME to 0700=E2= =80=A6. >=20 > That is what we are doing. Granted it generates a =E2=80=9Cfew=E2=80=9D fi= lesystems (like some 20000 per server (we have around 120k users), and then a= dd hourly snapshots to each as =E2=80=9Cicing=E2=80=9D on the cake). Mountin= g all those takes a bit of time - but luckily with the latest FreeBSD releas= e things are much faster these days :-) >=20 > There are some other issues with that - like 100% full filesystems causing= severe system slowdown during writes=E2=80=A6 So you really wanna have some= monitoring system that warns for that. >=20 > - Peter >=20 >=20 >>=20 >> I recently noticed that all ZFS filesystems in FreeBSD allow access to >> the .zfs directory (snapdir) for all users of the system. It is >> possible to hide that directory using the snapdir option: >=20 >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Fri Nov 8 07:03:56 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 7AB0C1A9319 for ; Fri, 8 Nov 2019 07:03:56 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 478WTR1WFBz3yGs for ; Fri, 8 Nov 2019 07:03:54 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CA4C64001D; Fri, 8 Nov 2019 08:03:51 +0100 (CET) Received: from [IPv6:2001:6b0:17:f002:dae:62ce:59cf:9d12] (unknown [IPv6:2001:6b0:17:f002:dae:62ce:59cf:9d12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id A332E4001C; Fri, 8 Nov 2019 08:03:51 +0100 (CET) From: Peter Eriksson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: ZFS snapdir readability (Crosspost) Date: Fri, 8 Nov 2019 08:03:52 +0100 References: <65AE896D-A32E-451A-B9D0-EC40D438BB03@gmail.com> To: Chris Watson , Jan Behrens , =?utf-8?Q?Karli_Sj=C3=B6berg_via_freebsd-fs?= In-Reply-To: <65AE896D-A32E-451A-B9D0-EC40D438BB03@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3601.0.10) X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 478WTR1WFBz3yGs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=liu.se; spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 130.236.254.3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se X-Spamd-Result: default: False [-4.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[3.254.236.130.list.dnswl.org : 127.0.11.2]; DMARC_POLICY_ALLOW(-0.50)[liu.se,none]; IP_SCORE(-1.60)[ipnet: 130.236.0.0/16(-4.43), asn: 2843(-3.54), country: SE(-0.03)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2843, ipnet:130.236.0.0/16, country:SE]; MID_RHS_MATCH_FROM(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 07:03:56 -0000 Yes, and no. We use =E2=80=98refquotas=E2=80=99 on the user filesystems = to prevent a user from using up all the free space in the zpool.=20 However, what happens is that ZFS will decrease the =E2=80=9Ctransaction = size=E2=80=9D of writes when a filesystem is nearly at quota in order to = prevent a transaction to write more than the assigned quota (since it = might write more due to compression/snapshots etc (or whatever)). Now = this is (apparently) by design and it works.=20 The effect is that a user trying to write to a nearly full (at quota) = filesystem will =E2=80=9Csee=E2=80=9D an extremely slow fileserver (from = MB/s to KB/s (or B/s if _really_ full) which makes for interesting bug = reports and problem diagnosing (since other users at the same time will = see no such slow-downs). _However_ - other effects are that creating snapshots, or destroying = snapshots _also_ can take longer than usual. Or if you delete a lot of = snapshots at the same time as a user has deleted a lot of files and you = then reboot the server - then when it starts up again and attempts to = mount all filesystems you will notice that it might take =E2=80=9Cforever=E2= =80=9D and it might look like =E2=80=9Czfs mount -a=E2=80=9D is = =E2=80=9Cstuck=E2=80=9D. Luckily for us when this happened we had = previously modified the system startup scripts so all zfs mounting is = done in the background and in parallell - so we got a login prompt and = could login and run some commands (normally all filesystems are mounted = first before allowing system logins=E2=80=A6.) So we logged in and noticed that it was doing a lot of writes (zpool = iostat) and was =E2=80=9Cstuck=E2=80=9D at attempting to mount a single = specific filesystem. A filesystem that happened to have 0 bytes free = refquota. When I added some 10G more =E2=80=98refquota=E2=80=99 to that = filesystem things speeded up a lot :-). (First time this happened we let the server finish mounting by itself - = which took about 2.5 days=E2=80=A6) - Peter > On 8 Nov 2019, at 01:31, Chris Watson wrote: >=20 > Peter, on your last point about 100% utilization, don=E2=80=99t you = use quotas/user quotas to prevent that? >=20 > Chris >=20 > Sent from my iPhone >=20 >> On Nov 7, 2019, at 4:06 PM, Peter Eriksson = wrote: >>=20 >> =EF=BB=BFThe =E2=80=9Ceasy=E2=80=9D solution is to give each user (or = group / project) their own ZFS filesystem. Then the =E2=80=9C.zfs=E2=80=9D= directory would be inside the users own $HOME and you can set $=08HOME = to 0700=E2=80=A6. >>=20 >> That is what we are doing. Granted it generates a =E2=80=9Cfew=E2=80=9D= filesystems (like some 20000 per server (we have around 120k users), = and then add hourly snapshots to each as =E2=80=9Cicing=E2=80=9D on the = cake). Mounting all those takes a bit of time - but luckily with the = latest FreeBSD release things are much faster these days :-) >>=20 >> There are some other issues with that - like 100% full filesystems = causing severe system slowdown during writes=E2=80=A6 So you really = wanna have some monitoring system that warns for that. >>=20 >> - Peter >>=20 >>=20 >>>=20 >>> I recently noticed that all ZFS filesystems in FreeBSD allow access = to >>> the .zfs directory (snapdir) for all users of the system. It is >>> possible to hide that directory using the snapdir option: >>=20 >>=20 >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" 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 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 From owner-freebsd-fs@freebsd.org Fri Nov 8 13:19:11 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 93A691B2270 for ; Fri, 8 Nov 2019 13:19:11 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 478gpQ4VVVz4LZH for ; Fri, 8 Nov 2019 13:19:10 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f178.google.com with SMTP id r7so6206400ljg.2 for ; Fri, 08 Nov 2019 05:19:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=7/ljfSbFH/uF3gGEfaTKgdyGAanOJm1nqcxKnJAjbHY=; b=SaSGCCw2Re0dPNiVWIZaalr2Q/7OTwghrPxsW+hoafqUUNOBD96kOFkm1cYItvxYdx Sfz0fgmXm8fc5oXe7eb7MANFRlcTG70iIHkcNJsX5CXVVR4vO/0dhTj76ySyXwxF9ssS I6/zeWhTqtSalvT0jcslj0OvztDIOaFzPDnE65ArWdxf3oqLEGrVSeL8KZHNaygYbBMs QO+rYGM5Z3jydWHpGC3yp5rCPiviXGKiMif5YuZVTg5sWDgmEWSPojZkJDhcqHiC9LrU H1OXh0dyav/SbeIf2gf5SgIkBJoqTnmUgKbScSy96cxq9mD+meiYFGLdBimt1WPUn/+w 0GVQ== X-Gm-Message-State: APjAAAWz8PMyw3h5Tp7NH5DX+0cmq02uYweEz9SEh70kYZo4L+GJM3bm 7DNOruRaTYL3LSqLsFmk0m05NnL9iLI= X-Google-Smtp-Source: APXvYqxUVdA6kGmxWdi2zPYYjDoRQQ2KYbSo/MGfxVG3JKlItilpZhMaRg86DlhKP/wjh6POe7IXtw== X-Received: by 2002:a2e:8608:: with SMTP id a8mr6963400lji.172.1573219148798; Fri, 08 Nov 2019 05:19:08 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q15sm2515652lfc.89.2019.11.08.05.19.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Nov 2019 05:19:08 -0800 (PST) Subject: Re: ZFS snapdir readability (Crosspost) To: Jan Behrens Cc: freebsd-fs@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> <20191108125226.4ffebc252e69c6cfa3c82165@magnetkern.de> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Fri, 8 Nov 2019 15:19:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191108125226.4ffebc252e69c6cfa3c82165@magnetkern.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 478gpQ4VVVz4LZH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-3.15 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[178.208.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-1.15)[ip: (-0.47), ipnet: 209.85.128.0/17(-3.20), asn: 15169(-2.01), country: US(-0.05)]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[178.208.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] 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 13:19:11 -0000 On 08/11/2019 13:52, Jan Behrens wrote: > 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. I would not object to having something like snapdirmode property. I think that it's reasonable. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Sat Nov 9 13:50:43 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 48D4D1AA68C for ; Sat, 9 Nov 2019 13:50:43 +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 479JSK6nfVz3HXT; Sat, 9 Nov 2019 13:50:41 +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 1FAD4AC9C; Sat, 9 Nov 2019 13:50:24 +0000 (UTC) Date: Sat, 9 Nov 2019 14:50:23 +0100 From: Jan Behrens To: Andriy Gapon Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191109145023.688cfa3e4b8271399814c4d2@magnetkern.de> In-Reply-To: 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> <20191108125226.4ffebc252e69c6cfa3c82165@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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 479JSK6nfVz3HXT 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.21 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.80)[-0.801,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.99)[-0.990,0]; IP_SCORE(0.28)[ipnet: 185.228.136.0/22(1.98), 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: Sat, 09 Nov 2019 13:50:43 -0000 On Fri, 8 Nov 2019 15:19:07 +0200 Andriy Gapon wrote: > On 08/11/2019 13:52, Jan Behrens wrote: > > [...] I believe adding an option to restrict > > readability of .zfs/snapdir to the owner of the root would > > significantly improve security, [...] > > I would not object to having something like snapdirmode property. > I think that it's reasonable. > > -- > Andriy Gapon Is it difficult to implement that? I assume it would require a new zfs pool feature to create such a new property? Regards, Jan