On Thu, 2018-05-31 at 12:00 +0200, Miklos Szeredi wrote:
> On Thu, May 31, 2018 at 2:45 AM, J. Bruce Fields <bfields@xxxxxxxxxxx
> g> wrote:
> > On Wed, May 30, 2018 at 05:33:11AM -0500, Goldwyn Rodrigues wrote:
> > > I am not trying to override the security. I am trying to detect
> > > duplication of security information. The common case of NFS
> > > communication does not require the additional security parameters
> > > (doesn't mean it is not required). So my question is: is it
> > > possible to
> > > detect at the client that nfs4_acl is a duplicate of information
> > > which
> > > can be and is represented by inode alone. If yes, can it be
> > > suppressed
> > > by the client.
> >
> > No, that's not possible.
> >
> > The user's identity could be mapped in various ways. You've got no
> > way
> > to know whether root squashing is in effect, for example. Or to
> > know
> > what the user@xxxxxxxxxxx krb5 identity that you're running as
> > might map
> > to on the server.
> >
> > So it's hard to even tell whether a given user matches the file's
> > owner
> > or group. So even the mode bits are kind of meaningless to the
> > client.
>
> The basic security model for overlayfs is that underlying filesystems
> are just storage. Access to these filesystems is done with the
> capabilities of the task that created the overlay instance with
> mount(2). That capability set is saved and used for any access to
> underlying storage.
>
> Access to overlayfs itself is controlled by metadata in the file
> (mode, uid, gid, posix_acl, security xattr, etc...).
>
> So if one of the layers is NFS, the permissions in the server are
> only
> checked against the mounter's creds (usually superuser). Access
> checks are not performed by the server on behalf of the task
> accessing
> the overlay. This means, that overlayfs could give access to an
> NFS
> file, where access on the NFS mount would be denied. This needs to
> be
> understood by the admin mounting the overlay.
>
> So how to handle nfs4_acls with this model?
>
> We could just ignore them and this can be achieved with mounting the
> NFS filesystem with "noacl". I'm not against specifically ignoring
> nfs4_acl in overlayfs by default, as that seems to be the simplest
> solution to this problem and fits the overlayfs security model.
> Later, if we want to make use of this attribute to check access (on
> the overlay, not in the NFS server), we can add an option to enable
> this. But AFAICS that one requires richacl's to make it upstream at
> least.
'noacl' does not mean what you think it means. It doesn't mean that the
NFS security model is changed in any way. Security is still enforced by
the server.
And no, richacl won't help you get further either.
I'm still in strong disagreement with the model you are presenting
here. It is a client enforced model, which is not ever going to be
compatible with the NFS model.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
