Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi <miklos@szeredi.hu>]

On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust
<trondmy@hammerspace.com> wrote:
> On Thu, 2018-05-31 at 14:55 +0200, Miklos Szeredi wrote:
>> On Thu, May 31, 2018 at 2:47 PM, Trond Myklebust
>> <trondmy@hammerspace.com> wrote:
>> > 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@fieldse
>> > > s.or
>> > > 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@EXAMPLE.COM 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.
>>
>> I understand.  Ignoring nfs4_acl in overlayfs will have the same
>> result as adding noacl to the underlying NFS mount.
>>
>> > 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.
>>
>> It's the only sane model that overlayfs can do.
>>
>> Think of it this way:  creating an image file on NFS, formating it to
>> ext4 and mounting it locally through the loop device is not going to
>> be compatible with the NFS security model either.  Should we care?
>
> Yes you should care because you are proposing that the simple act of
> mounting through overlayfs will change who can access, read and modify
> existing files from a NFS server.

Only access/read: NFS can only be read-only layer.  So it's impossible
to actually modify a file on NFS through overlayfs.

>
> The model for overlayfs and all unionfs should be that security is
> enforced by the underlying filesystem _UNTIL_ the access mode is
> modified on the top level filesystem.

How?

We've been through this.  We can't ask an NFS server exported
read-only about what the permission to modify the filesystem would
have been if it were exported read-write.  Sure, the protocol could be
extended, etc, etc...  But it's just not a good fit.

>
> IOW: if the user does a chmod, and that is authorised by the underlying
> filesystem, then overlayfs is in charge of any further authorisation to
> that file.
> Adding richacls to that model means that you can attempt to copy the
> ACL and allow the user to modify that instead of doing the chmod, but
> the understanding should be that it's not the same ACL as was been
> enforced by the server, so the copy up of the ACL should be treated as
> a modification of the ACL (and should therefore first be subject to
> authorisation by the server).

If someone adds the interface for access checking in the NFS client
based on server sercurity model, but without actually having to do the
request, and it works for read-only exports (which make a LOT of sense
for the use cases where overlayfs may be used with NFS) then we can
use that from overlayfs.  Last time Bruce looked this issue, he ran
away screeming, IIRC.

Thanks,
Miklos