Date: Wed, 20 Nov 2019 11:07:24 +0100 From: Borja Marcos <borjam@sarenet.es> To: mike tancsa <mike@sentex.net> Cc: Alan Somers <asomers@freebsd.org>, Jan Behrens <jbe-mlist@magnetkern.de>, freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: ZFS snapdir readability (Crosspost) Message-ID: <261FE331-EC5C-48C8-9249-9BCBF887CE38@sarenet.es> In-Reply-To: <cfcc12dd-e9eb-5a98-a031-ab18436a2dd3@sentex.net> References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <CAOtMX2huHZcXHH%2B=3Bx7hX_p9udJ2acOX%2BZL8vW=pjqbe6mOAA@mail.gmail.com> <e2eecef7-21b6-0ff2-b259-71421b7d097c@sentex.net> <9B22AD46-BE87-4305-9638-74D23AD4C8CA@sarenet.es> <cfcc12dd-e9eb-5a98-a031-ab18436a2dd3@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 18 Nov 2019, at 14:09, mike tancsa <mike@sentex.net> wrote: >=20 > On 11/18/2019 5:01 AM, Borja Marcos wrote: >>=20 >>> 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. >>>=20 >>> https://github.com/zfsonlinux/zfs/issues/3963 >> The problem is, snapshot access breaks the semantics of chown() and = chmod(). >>=20 > As the snapshots are always readonly, I think chown and chmod dont > really apply in this use case. Also, the fact that the mounts can be = set > to be "visibile" or "invisible" has its own, different convention from > UFS/NFS who dont have that "invisibility" feature (that I know of = anyway). That=E2=80=99s what I mean with breaking the semantics. When you change permissions on a file they apply to open() operations = attempted after the permissions/ownership change.=20 Now, if you add ZFS snapshots to the equation the situation is = different. If you change permissions/ownership on a file, access rights are not changed for the = snapshots because snapshots are read only. So, your file is still exposed.=20 > Maybe a lesser evil would be to define a uid with snapshot access for = each dataset. At least >> for systems with a dataset per home directory it would allow a user = to access their past snapshots >> while at the same time restricting to past snapshots to other users. >=20 > the problem is you could have a "rogue" snapshot. eg. a user does = chmod > a+rx ~ and leaves it on by mistake for a day. Any snapshots kept from > that period would leave that directory open. I think having a = "snapshots > not mounted" option adds a layer of security flexibility safety.=20 Yes, I mean that, as a lesser evil, those snapshots would be accessible = only to the dataset owner (either defined by a new attribute, or just determined by the owner of = the dataset root directory). That would offer the convenience of instantly accessible snapshots as an = instant access backup for HOME directories. You could make snapshots not mounted, period, requiring = administrator=E2=80=99s actions to mount them. But you would lose convenience for common users.=20 Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?261FE331-EC5C-48C8-9249-9BCBF887CE38>