Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Nov 2019 11:01:26 +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:  <9B22AD46-BE87-4305-9638-74D23AD4C8CA@sarenet.es>
In-Reply-To: <e2eecef7-21b6-0ff2-b259-71421b7d097c@sentex.net>
References:  <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <CAOtMX2huHZcXHH%2B=3Bx7hX_p9udJ2acOX%2BZL8vW=pjqbe6mOAA@mail.gmail.com> <e2eecef7-21b6-0ff2-b259-71421b7d097c@sentex.net>

next in thread | previous in thread | raw e-mail | index | archive | help


> On 7 Nov 2019, at 15:54, mike tancsa <mike@sentex.net> wrote:
>=20
> On 11/6/2019 7:02 PM, Alan Somers wrote:
>>=20
>> 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.
>=20
> 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().

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.




Borja.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9B22AD46-BE87-4305-9638-74D23AD4C8CA>