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: > > On 11/18/2019 5:01 AM, Borja Marcos wrote: >> >>> 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 >> The problem is, snapshot access breaks the semantics of chown() and chmod(). >> > 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’s 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. 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. > 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. > > 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. 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’s actions to mount them. But you would lose convenience for common users. Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?261FE331-EC5C-48C8-9249-9BCBF887CE38>