nfs4_acl restricts copy_up in overlayfs

nfs4_acl restricts copy_up in overlayfs

[Goldwyn Rodrigues]

While mounting overlayfs with NFS as a lower directory and a local
filesystem as an upper layer leads to copy_up failures because NFS4 has
an extra system.nfs4_acl which cannot be copied up. This has been
discussed before [1] and [2] with the suggestion that nfs4_acl is
derived from posix_acls or just inode->i_mode *most* of the times and
hence it can be mapped back.

The problem is NFS client knows nothing about nfs4_acl and it is decoded
in nfs4-acl-tools. Even if we make nfs client capable of understand
nfs4_acl xattr, can it be used to perform ACL's for the system. AFAIU,
it is uses user/group names as opposed uid/gid to perform id mapping.
Can the client map it back to user names and derive if it is just an
replica of inode's i_mode?

The idea is to suppress nfs4_acl if it is the same as inode's i_mode.
This means nfs4-acl-tools/nfs4_getacl would give no results when
requesting for ACLs. This would break existing applications if they
expect some output from nfs4_getfacl.

Is there a better way to identify if nfs4_acl is just a representation
of i_mode at the client end and can be safely ignored during an
overlayfs copy_up? Can we include a flag for this?


[1] https://www.spinics.net/lists/linux-nfs/msg61045.html
[2] https://www.spinics.net/lists/linux-unionfs/msg04736.html

-- 
Goldwyn

Re: nfs4_acl restricts copy_up in overlayfs

[Trond Myklebust]

On Tue, 2018-05-29 at 15:32 -0500, Goldwyn Rodrigues wrote:
> While mounting overlayfs with NFS as a lower directory and a local
> filesystem as an upper layer leads to copy_up failures because NFS4
> has
> an extra system.nfs4_acl which cannot be copied up. This has been
> discussed before [1] and [2] with the suggestion that nfs4_acl is
> derived from posix_acls or just inode->i_mode *most* of the times and
> hence it can be mapped back.
> 
> The problem is NFS client knows nothing about nfs4_acl and it is
> decoded
> in nfs4-acl-tools. Even if we make nfs client capable of understand
> nfs4_acl xattr, can it be used to perform ACL's for the system.
> AFAIU,
> it is uses user/group names as opposed uid/gid to perform id mapping.
> Can the client map it back to user names and derive if it is just an
> replica of inode's i_mode?
> 
> The idea is to suppress nfs4_acl if it is the same as inode's i_mode.
> This means nfs4-acl-tools/nfs4_getacl would give no results when
> requesting for ACLs. This would break existing applications if they
> expect some output from nfs4_getfacl.
> 
> Is there a better way to identify if nfs4_acl is just a
> representation
> of i_mode at the client end and can be safely ignored during an
> overlayfs copy_up? Can we include a flag for this?
> 
> 
> [1] https://www.spinics.net/lists/linux-nfs/msg61045.html
> [2] https://www.spinics.net/lists/linux-unionfs/msg04736.html
> 

If the permissions are unchanged so that overlayfs is not trying to
override the way the server interprets the ACL, and credential held by
the user, then you are better off calling the Linux client for
open/close and permissions calls.

Once you've allowed the user to chmod or chown the file, you are on
your own, because your security model for the file will have forked
with the security model provided by NFS. At that point, the file had
better have been copied up, and you'd better be ready to manage it
entirely from overlayfs.

The above applies not only when the file is subject to NFSv4 acls, but
it is also true when you are using strong authentication (i.e. Kerberos
V).

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: nfs4_acl restricts copy_up in overlayfs

[Goldwyn Rodrigues]

On 05/29/2018 04:37 PM, Trond Myklebust wrote:
> On Tue, 2018-05-29 at 15:32 -0500, Goldwyn Rodrigues wrote:
>> While mounting overlayfs with NFS as a lower directory and a local
>> filesystem as an upper layer leads to copy_up failures because NFS4
>> has
>> an extra system.nfs4_acl which cannot be copied up. This has been
>> discussed before [1] and [2] with the suggestion that nfs4_acl is
>> derived from posix_acls or just inode->i_mode *most* of the times and
>> hence it can be mapped back.
>>
>> The problem is NFS client knows nothing about nfs4_acl and it is
>> decoded
>> in nfs4-acl-tools. Even if we make nfs client capable of understand
>> nfs4_acl xattr, can it be used to perform ACL's for the system.
>> AFAIU,
>> it is uses user/group names as opposed uid/gid to perform id mapping.
>> Can the client map it back to user names and derive if it is just an
>> replica of inode's i_mode?
>>
>> The idea is to suppress nfs4_acl if it is the same as inode's i_mode.
>> This means nfs4-acl-tools/nfs4_getacl would give no results when
>> requesting for ACLs. This would break existing applications if they
>> expect some output from nfs4_getfacl.
>>
>> Is there a better way to identify if nfs4_acl is just a
>> representation
>> of i_mode at the client end and can be safely ignored during an
>> overlayfs copy_up? Can we include a flag for this?
>>
>>
>> [1] https://www.spinics.net/lists/linux-nfs/msg61045.html
>> [2] https://www.spinics.net/lists/linux-unionfs/msg04736.html
>>
> 
> If the permissions are unchanged so that overlayfs is not trying to
> override the way the server interprets the ACL, and credential held by
> the user, then you are better off calling the Linux client for
> open/close and permissions calls.
> 
> Once you've allowed the user to chmod or chown the file, you are on
> your own, because your security model for the file will have forked
> with the security model provided by NFS. At that point, the file had
> better have been copied up, and you'd better be ready to manage it
> entirely from overlayfs.
> 
> The above applies not only when the file is subject to NFSv4 acls, but
> it is also true when you are using strong authentication (i.e. Kerberos
> V).
> 

The files permissions are checked during copy ups because a data copy
also happens in case of a change. The problem however is not the checks
have to happen for this operation but if we should bypass NFS security
for consequent ones.

For example, If we copy_up the file just because the current user is
able to, it would not copy the nfs4_acl. If there is a NFS4 acl rule to
DENY another user, the earlier denied user will be able to access the
file after the copy_up because we did not copy the nfs4_acl.

Overlayfs tries to make sure that all xattr from an underlying
filesystem is compatible with the one being copied to. nfs4_acl is not
compatible with a local filesystem it rejects the copy_up as EOPNOTSUPP.

>From the nfsd code (nfsd_get_nfs4_acl), in *most* cases nfs4_acl is just
a representation of i_mode and does not require a special ACL. However,
just because there is a nfs4_acl, a copy_up does not happen in the client.

-- 
Goldwyn

Re: nfs4_acl restricts copy_up in overlayfs

[Trond Myklebust]

On Tue, 2018-05-29 at 20:08 -0500, Goldwyn Rodrigues wrote:
> 
> On 05/29/2018 04:37 PM, Trond Myklebust wrote:
> > On Tue, 2018-05-29 at 15:32 -0500, Goldwyn Rodrigues wrote:
> > > While mounting overlayfs with NFS as a lower directory and a
> > > local
> > > filesystem as an upper layer leads to copy_up failures because
> > > NFS4
> > > has
> > > an extra system.nfs4_acl which cannot be copied up. This has been
> > > discussed before [1] and [2] with the suggestion that nfs4_acl is
> > > derived from posix_acls or just inode->i_mode *most* of the times
> > > and
> > > hence it can be mapped back.
> > > 
> > > The problem is NFS client knows nothing about nfs4_acl and it is
> > > decoded
> > > in nfs4-acl-tools. Even if we make nfs client capable of
> > > understand
> > > nfs4_acl xattr, can it be used to perform ACL's for the system.
> > > AFAIU,
> > > it is uses user/group names as opposed uid/gid to perform id
> > > mapping.
> > > Can the client map it back to user names and derive if it is just
> > > an
> > > replica of inode's i_mode?
> > > 
> > > The idea is to suppress nfs4_acl if it is the same as inode's
> > > i_mode.
> > > This means nfs4-acl-tools/nfs4_getacl would give no results when
> > > requesting for ACLs. This would break existing applications if
> > > they
> > > expect some output from nfs4_getfacl.
> > > 
> > > Is there a better way to identify if nfs4_acl is just a
> > > representation
> > > of i_mode at the client end and can be safely ignored during an
> > > overlayfs copy_up? Can we include a flag for this?
> > > 
> > > 
> > > [1] https://www.spinics.net/lists/linux-nfs/msg61045.html
> > > [2] https://www.spinics.net/lists/linux-unionfs/msg04736.html
> > > 
> > 
> > If the permissions are unchanged so that overlayfs is not trying to
> > override the way the server interprets the ACL, and credential held
> > by
> > the user, then you are better off calling the Linux client for
> > open/close and permissions calls.
> > 
> > Once you've allowed the user to chmod or chown the file, you are on
> > your own, because your security model for the file will have forked
> > with the security model provided by NFS. At that point, the file
> > had
> > better have been copied up, and you'd better be ready to manage it
> > entirely from overlayfs.
> > 
> > The above applies not only when the file is subject to NFSv4 acls,
> > but
> > it is also true when you are using strong authentication (i.e.
> > Kerberos
> > V).
> > 
> 
> The files permissions are checked during copy ups because a data copy
> also happens in case of a change. The problem however is not the
> checks
> have to happen for this operation but if we should bypass NFS
> security
> for consequent ones.
> 
> For example, If we copy_up the file just because the current user is
> able to, it would not copy the nfs4_acl. If there is a NFS4 acl rule
> to
> DENY another user, the earlier denied user will be able to access the
> file after the copy_up because we did not copy the nfs4_acl.
> 

As I said, you are forking the security model. You are trying to make
the NFS client act as a proxy for the NFS server without giving it
enough information to do so.

The NFS client is careful to _always_ leave interpreting the ACL, mode,
and other security information to the server. If it must try to act as
a proxy for the server when serving up cached information, then it uses
the ACCESS rpc call to ensure that it doesn't give up information that
the server would normally deny to a particular user.

> Overlayfs tries to make sure that all xattr from an underlying
> filesystem is compatible with the one being copied to. nfs4_acl is
> not
> compatible with a local filesystem it rejects the copy_up as
> EOPNOTSUPP.
> 
> From the nfsd code (nfsd_get_nfs4_acl), in *most* cases nfs4_acl is
> just
> a representation of i_mode and does not require a special ACL. 

If your server is a knfsd based Linux server, then maybe. If it's
anything else, then the above statement is dead wrong. Either way,
you'd be opening a large can of security worms by making those
assumptions.

> However,
> just because there is a nfs4_acl, a copy_up does not happen in the
> client.

Which would appear to be the more secure behaviour if you are unable to
enforce the exact same security semantics as the server.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: nfs4_acl restricts copy_up in overlayfs

[Goldwyn Rodrigues]

On 05/29/2018 10:01 PM, Trond Myklebust wrote:
> On Tue, 2018-05-29 at 20:08 -0500, Goldwyn Rodrigues wrote:
>>
>> On 05/29/2018 04:37 PM, Trond Myklebust wrote:
>>> On Tue, 2018-05-29 at 15:32 -0500, Goldwyn Rodrigues wrote:
>>>> While mounting overlayfs with NFS as a lower directory and a
>>>> local
>>>> filesystem as an upper layer leads to copy_up failures because
>>>> NFS4
>>>> has
>>>> an extra system.nfs4_acl which cannot be copied up. This has been
>>>> discussed before [1] and [2] with the suggestion that nfs4_acl is
>>>> derived from posix_acls or just inode->i_mode *most* of the times
>>>> and
>>>> hence it can be mapped back.
>>>>
>>>> The problem is NFS client knows nothing about nfs4_acl and it is
>>>> decoded
>>>> in nfs4-acl-tools. Even if we make nfs client capable of
>>>> understand
>>>> nfs4_acl xattr, can it be used to perform ACL's for the system.
>>>> AFAIU,
>>>> it is uses user/group names as opposed uid/gid to perform id
>>>> mapping.
>>>> Can the client map it back to user names and derive if it is just
>>>> an
>>>> replica of inode's i_mode?
>>>>
>>>> The idea is to suppress nfs4_acl if it is the same as inode's
>>>> i_mode.
>>>> This means nfs4-acl-tools/nfs4_getacl would give no results when
>>>> requesting for ACLs. This would break existing applications if
>>>> they
>>>> expect some output from nfs4_getfacl.
>>>>
>>>> Is there a better way to identify if nfs4_acl is just a
>>>> representation
>>>> of i_mode at the client end and can be safely ignored during an
>>>> overlayfs copy_up? Can we include a flag for this?
>>>>
>>>>
>>>> [1] https://www.spinics.net/lists/linux-nfs/msg61045.html
>>>> [2] https://www.spinics.net/lists/linux-unionfs/msg04736.html
>>>>
>>>
>>> If the permissions are unchanged so that overlayfs is not trying to
>>> override the way the server interprets the ACL, and credential held
>>> by
>>> the user, then you are better off calling the Linux client for
>>> open/close and permissions calls.
>>>
>>> Once you've allowed the user to chmod or chown the file, you are on
>>> your own, because your security model for the file will have forked
>>> with the security model provided by NFS. At that point, the file
>>> had
>>> better have been copied up, and you'd better be ready to manage it
>>> entirely from overlayfs.
>>>
>>> The above applies not only when the file is subject to NFSv4 acls,
>>> but
>>> it is also true when you are using strong authentication (i.e.
>>> Kerberos
>>> V).
>>>
>>
>> The files permissions are checked during copy ups because a data copy
>> also happens in case of a change. The problem however is not the
>> checks
>> have to happen for this operation but if we should bypass NFS
>> security
>> for consequent ones.
>>
>> For example, If we copy_up the file just because the current user is
>> able to, it would not copy the nfs4_acl. If there is a NFS4 acl rule
>> to
>> DENY another user, the earlier denied user will be able to access the
>> file after the copy_up because we did not copy the nfs4_acl.
>>
> 
> As I said, you are forking the security model. You are trying to make
> the NFS client act as a proxy for the NFS server without giving it
> enough information to do so.
> 
> The NFS client is careful to _always_ leave interpreting the ACL, mode,
> and other security information to the server. If it must try to act as
> a proxy for the server when serving up cached information, then it uses
> the ACCESS rpc call to ensure that it doesn't give up information that
> the server would normally deny to a particular user.

I am in agreement with the security model and that is what I want to
preserve. My question is if it is possible to detect that the security
can be represented by existing in-inode security features alone.

If it was up to me, I would not create the nfs4_acl xattr at the server
if it is not required and the security can be represented by existing
parameters, but it seems to be the protocol. To give a comparison, in
local filsystems, if "system.posix_acl" is not required it will not be
created.

> 
>> Overlayfs tries to make sure that all xattr from an underlying
>> filesystem is compatible with the one being copied to. nfs4_acl is
>> not
>> compatible with a local filesystem it rejects the copy_up as
>> EOPNOTSUPP.
>>
>> From the nfsd code (nfsd_get_nfs4_acl), in *most* cases nfs4_acl is
>> just
>> a representation of i_mode and does not require a special ACL. 
> 
> If your server is a knfsd based Linux server, then maybe. If it's
> anything else, then the above statement is dead wrong. Either way,
> you'd be opening a large can of security worms by making those
> assumptions.

I agree. The man page says there are features (such as alarm and audit)
which are server dependent.

> 
>> However,
>> just because there is a nfs4_acl, a copy_up does not happen in the
>> client.
> 
> Which would appear to be the more secure behaviour if you are unable to
> enforce the exact same security semantics as the server.

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.

-- 
Goldwyn

Re: nfs4_acl restricts copy_up in overlayfs

[J. Bruce Fields]

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.

--b.

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

On Thu, May 31, 2018 at 2:45 AM, J. Bruce Fields <bfields@fieldses.org> 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.

Thanks,
Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[Trond Myklebust]

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@fieldses.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.

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@hammerspace.com

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

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@fieldses.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?

Thanks,
Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[Trond Myklebust]

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.

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.

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).

-- 
Trond Myklebust
CTO, Hammerspace Inc
4300 El Camino Real, Suite 105
Los Altos, CA 94022
www.hammer.space id="-x-evo-selection-end-marker">

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

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

Re: nfs4_acl restricts copy_up in overlayfs

[bfields]

On Thu, May 31, 2018 at 03:30:04PM +0200, Miklos Szeredi wrote:
> 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:
> >> > 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.

In addition to being read-only, I assume it's also unchanging?  I wonder
why you'd want to use NFS at all for this case--sharing a read-only
ext4-formatted block device would seem more straightforward.

Apologies if we've been through this before too, I've long ago paged out
any previous conversation....

> > 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.

In theory I suppose it's all possible, but I think the only practical
thing to do for now is just ignore NFSv4 ACLs.

--b.

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

On Thu, May 31, 2018 at 4:06 PM, bfields@fieldses.org
<bfields@fieldses.org> wrote:
> On Thu, May 31, 2018 at 03:30:04PM +0200, Miklos Szeredi wrote:
>> 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:
>> >> > 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.
>
> In addition to being read-only, I assume it's also unchanging?  I wonder
> why you'd want to use NFS at all for this case--sharing a read-only
> ext4-formatted block device would seem more straightforward.

Actually we could allow changes on the server side.   Overlayfs sort
of does this already (calls underlying fs's ->d_revalidate() from
ovl_dentry_revalidate()).  What's still needed is to detect rename by
rechecking parent and d_name to match overlay dentry's parent and
d_name.

But a shared block dev could be used in most cases, I guess.

Thanks,
Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[Trond Myklebust]

On Thu, 2018-05-31 at 16:26 +0200, Miklos Szeredi wrote:
> On Thu, May 31, 2018 at 4:06 PM, bfields@fieldses.org
> <bfields@fieldses.org> wrote:
> > On Thu, May 31, 2018 at 03:30:04PM +0200, Miklos Szeredi wrote:
> > > 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@ham
> > > > > merspace.com> wrote:
> > > > > > 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.
> > 
> > In addition to being read-only, I assume it's also unchanging?  I
> > wonder
> > why you'd want to use NFS at all for this case--sharing a read-only
> > ext4-formatted block device would seem more straightforward.
> 
> Actually we could allow changes on the server side.   Overlayfs sort
> of does this already (calls underlying fs's ->d_revalidate() from
> ovl_dentry_revalidate()).  What's still needed is to detect rename by
> rechecking parent and d_name to match overlay dentry's parent and
> d_name.
> 
> But a shared block dev could be used in most cases, I guess.
> 

Why would you need to export the filesystem as read-only if it is going
to be overlayed anyway? Do the read-only protection on the client side.

-- 
Trond Myklebust
CTO, Hammerspace Inc
4300 El Camino Real, Suite 105
Los Altos, CA 94022
www.hammer.space id="-x-evo-selection-end-marker">

Re: nfs4_acl restricts copy_up in overlayfs

[J. R. Okajima]

Trond Myklebust:
> 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.

Agreed.
For your information, here is aufs's fundamental approach.
- don't change the task credential.
- support the writable NFS layer.
- respect the layer fs's security model.

In the case of "upper RW non-NFS + lower RO NFS layers" combination,
nfs4_acl can be a problem in the internal (copy,move)-(up,down). Yes,
this is common to overlayfs. In order to address this, aufs introduced a
rather generic solution called ICEX (Ignore Copy-Error on Xattr) and
specifying the mount option saves users from the internal error.
Still I don't think this is best and ideal solution, but the
"ignoring conditially" is a realistic solution.


(from aufs manual)
----------------------------------------
.TP
.B icexsec | icexsys | icextr | icexusr | icexoth | icex
Ignore the error on copying\-up/down XATTR.
When an internal copy\-up/down happens, aufs tries copying all XATTRs.
Here an error can happen because of the XATTR support on the dst
branch may different from the src branch. If you know how the branch
supports or unsupports XATTR, you can specify these attributes.
`icexsec' means to ignore an error on copying\-up/down XATTR categorized
as "security" (for LSM and capability). And `icexsys,' `icextr,' and
`icexusr,' are for "system" (for posix ACL), "trusted" and "user"
categories individually.
`icexoth' is for any other category. To be convenient, `icex` sets them
all.
See also linux/Documentation/filesystems/aufs/design/06xattr.txt.

(from linux/Documentation/filesystems/aufs/design/06xattr.txt in aufs source tree)
----------------------------------------
Generally the extended attributes of inode are categorized as these.
- "security" for LSM and capability.
- "system" for posix ACL, 'acl' mount option is required for the branch
  fs generally.
- "trusted" for userspace, CAP_SYS_ADMIN is required.
- "user" for userspace, 'user_xattr' mount option is required for the
  branch fs generally.

Moreover there are some other categories. Aufs handles these rather
unpopular categories as the ordinary ones, ie. there is no special
condition nor exception.

In copy-up, the support for XATTR on the dst branch may differ from the
src branch. In this case, the copy-up operation will get an error and
the original user operation which triggered the copy-up will fail. It
can happen that even all copy-up will fail.
When both of src and dst branches support XATTR and if an error occurs
during copying XATTR, then the copy-up should fail obviously. That is a
good reason and aufs should return an error to userspace. But when only
the src branch support that XATTR, aufs should not return an error.
For example, the src branch supports ACL but the dst branch doesn't
because the dst branch may natively un-support it or temporary
un-support it due to "noacl" mount option. Of course, the dst branch fs
may NOT return an error even if the XATTR is not supported. It is
totally up to the branch fs.

Anyway when the aufs internal copy-up gets an error from the dst branch
fs, then aufs tries removing the just copied entry and returns the error
to the userspace. The worst case of this situation will be all copy-up
will fail.

For the copy-up operation, there two basic approaches.
- copy the specified XATTR only (by category above), and return the
  error unconditionally if it happens.
- copy all XATTR, and ignore the error on the specified category only.

In order to support XATTR and to implement the correct behaviour, aufs
chooses the latter approach and introduces some new branch attributes,
"icexsec", "icexsys", "icextr", "icexusr", and "icexoth".
They correspond to the XATTR namespaces (see above). Additionally, to be
convenient, "icex" is also provided which means all "icex*" attributes
are set (here the word "icex" stands for "ignore copy-error on XATTR").

The meaning of these attributes is to ignore the error from setting
XATTR on that branch.
Note that aufs tries copying all XATTR unconditionally, and ignores the
error from the dst branch according to the specified attributes.

Some XATTR may have its default value. The default value may come from
the parent dir or the environment. If the default value is set at the
file creating-time, it will be overwritten by copy-up.
Some contradiction may happen I am afraid.
Do we need another attribute to stop copying XATTR? I am unsure. For
now, aufs implements the branch attributes to ignore the error.



J. R. Okajima

Re: nfs4_acl restricts copy_up in overlayfs

[Goldwyn Rodrigues]

On 05/31/2018 08:30 AM, Miklos Szeredi wrote:
> On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust
> <trondmy@hammerspace.com> wrote:

>>>
>>> I understand.  Ignoring nfs4_acl in overlayfs will have the same
>>> result as adding noacl to the underlying NFS mount.

Adding noacl in NFS client mount has no affect to nfs4_acl. Only if you
add noacl in the underlying filesystem of exported directory in the
server does the nfs4_acl go away.

-- 
Goldwyn

Re: nfs4_acl restricts copy_up in overlayfs

[Goldwyn Rodrigues]

On 05/31/2018 09:06 AM, bfields@fieldses.org wrote:
> On Thu, May 31, 2018 at 03:30:04PM +0200, Miklos Szeredi wrote:
>> 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:
>>>
>>> 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.
> 
> In theory I suppose it's all possible, but I think the only practical
> thing to do for now is just ignore NFSv4 ACLs.
> 

Ignoring nfs4_acl will override the NFS security model where a user
which is specifically denied read access in the nfs4_acl will get read
access if another user who is allowed to read/write edits the file.

I would agree ignoring NFS4 ACLs is the best option.


-- 
Goldwyn

Re: nfs4_acl restricts copy_up in overlayfs

[Trond Myklebust]

On Thu, 2018-05-31 at 16:53 -0500, Goldwyn Rodrigues wrote:
> 
> On 05/31/2018 08:30 AM, Miklos Szeredi wrote:
> > On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust
> > <trondmy@hammerspace.com> wrote:
> > > > 
> > > > I understand.  Ignoring nfs4_acl in overlayfs will have the
> > > > same
> > > > result as adding noacl to the underlying NFS mount.
> 
> Adding noacl in NFS client mount has no affect to nfs4_acl. Only if
> you
> add noacl in the underlying filesystem of exported directory in the
> server does the nfs4_acl go away.

That would also be specific to Linux servers.

So if that is your final decision, then why not just state in the
overlayfs manpage that

"Our security model assumes that you are using a NFSv3-only Linux knfsd
based server that has mounted the filesystem with the 'noacl' option,
that exports the filesystem with sec=sys only, has disabled server side
identity squashing and has disabled the --manage-gids mountd option"? 

At least that would be honest...

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: nfs4_acl restricts copy_up in overlayfs

[Goldwyn Rodrigues]

On 05/31/2018 07:49 PM, Trond Myklebust wrote:
> On Thu, 2018-05-31 at 16:53 -0500, Goldwyn Rodrigues wrote:
>>
>> On 05/31/2018 08:30 AM, Miklos Szeredi wrote:
>>> On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust
>>> <trondmy@hammerspace.com> wrote:
>>>>>
>>>>> I understand.  Ignoring nfs4_acl in overlayfs will have the
>>>>> same
>>>>> result as adding noacl to the underlying NFS mount.
>>
>> Adding noacl in NFS client mount has no affect to nfs4_acl. Only if
>> you
>> add noacl in the underlying filesystem of exported directory in the
>> server does the nfs4_acl go away.
> 
> That would also be specific to Linux servers.

Sorry, I don't have access to other NFS based servers. Does that mean
"noacl" option on NFS client mount has different interpretations for
different NFS servers? Or do you mean that nfs4_acl cannot be disabled
for other type of servers?

> 
> So if that is your final decision, then why not just state in the
> overlayfs manpage that

No, that is not my final decision. Neither is it for me to make. I am
merely trying to find a way to make writes on overlayfs possible with
NFSv4 in the lower layer.


-- 
Goldwyn

Re: nfs4_acl restricts copy_up in overlayfs

[Trond Myklebust]

On Fri, 2018-06-01 at 06:40 -0500, Goldwyn Rodrigues wrote:
> 
> On 05/31/2018 07:49 PM, Trond Myklebust wrote:
> > On Thu, 2018-05-31 at 16:53 -0500, Goldwyn Rodrigues wrote:
> > > 
> > > On 05/31/2018 08:30 AM, Miklos Szeredi wrote:
> > > > On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust
> > > > <trondmy@hammerspace.com> wrote:
> > > > > > 
> > > > > > I understand.  Ignoring nfs4_acl in overlayfs will have the
> > > > > > same
> > > > > > result as adding noacl to the underlying NFS mount.
> > > 
> > > Adding noacl in NFS client mount has no affect to nfs4_acl. Only
> > > if
> > > you
> > > add noacl in the underlying filesystem of exported directory in
> > > the
> > > server does the nfs4_acl go away.
> > 
> > That would also be specific to Linux servers.
> 
> Sorry, I don't have access to other NFS based servers. Does that mean
> "noacl" option on NFS client mount has different interpretations for
> different NFS servers? Or do you mean that nfs4_acl cannot be
> disabled
> for other type of servers?

I'm not sure it even makes sense to turn off filesystem acls if your
underlying filesystem is something like zfs or apfs (let alone NTFS).
Linux really is behind the curve here.

> > 
> > So if that is your final decision, then why not just state in the
> > overlayfs manpage that
> 
> No, that is not my final decision. Neither is it for me to make. I am
> merely trying to find a way to make writes on overlayfs possible with
> NFSv4 in the lower layer.
> 

...and all I'm doing is pointing out that as long as you insist on
client enforcement of file security, then you are heavily limiting the
list of servers and server configurations that you will be able to work
safely with. There is a reason why, in all the 30 years since the NFSv2
spec was released, nobody has built such a client.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

On Fri, Jun 1, 2018 at 3:16 PM, Trond Myklebust <trondmy@hammerspace.com> wrote:

> ...and all I'm doing is pointing out that as long as you insist on
> client enforcement of file security, then you are heavily limiting the
> list of servers and server configurations that you will be able to work
> safely with. There is a reason why, in all the 30 years since the NFSv2
> spec was released, nobody has built such a client.

How do you define "safely"?

Is it safe for root to do

  cp -a /nfs/remotedir /tmp/localdir

?

That's essentially what an overlayfs mount with an NFS layer does with
respect to access permissions:

 - remote files are not modifiable to anyone, unless server allows

 - remote files *readable to root* will provide access based on local DAC check.

Does that need to be made clear in the docs?  Surely.  But it does NOT
mean it's dangerous or that it's not useful with an arbitrary NFS
server (although my guess is that 99% will involve knfsd).

Thanks,
Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[bfields]

On Fri, Jun 01, 2018 at 03:32:59PM +0200, Miklos Szeredi wrote:
> How do you define "safely"?
> 
> Is it safe for root to do
> 
>   cp -a /nfs/remotedir /tmp/localdir
> 
> ?
> 
> That's essentially what an overlayfs mount with an NFS layer does with
> respect to access permissions:
> 
>  - remote files are not modifiable to anyone, unless server allows
> 
>  - remote files *readable to root* will provide access based on local DAC check.
> 
> Does that need to be made clear in the docs?  Surely.  But it does NOT
> mean it's dangerous or that it's not useful with an arbitrary NFS
> server

We should definitely have clear documentation, but despite that, in
practice lots of people *will* be surprised when permissions are
enforced differently after copy-up, and those surprises may well have
unpleasant implications.

And the differences will depend on details of the server implementation,
which makes documenting the behavior and giving people the correct
expectations that much more complicated.

> (although my guess is that 99% will involve knfsd).

Why is that?  There are a *lot* of Linux clients out there talking to
non-knfsd servers.  I wouldn't have thought knfsd is even a
majority--but of course it depends very much on what kind of use exactly
we're measuring.  And I don't have any numbers.

--b.

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

On Fri, Jun 1, 2018 at 3:50 PM, bfields@fieldses.org
<bfields@fieldses.org> wrote:
> On Fri, Jun 01, 2018 at 03:32:59PM +0200, Miklos Szeredi wrote:
>> How do you define "safely"?
>>
>> Is it safe for root to do
>>
>>   cp -a /nfs/remotedir /tmp/localdir
>>
>> ?
>>
>> That's essentially what an overlayfs mount with an NFS layer does with
>> respect to access permissions:
>>
>>  - remote files are not modifiable to anyone, unless server allows
>>
>>  - remote files *readable to root* will provide access based on local DAC check.
>>
>> Does that need to be made clear in the docs?  Surely.  But it does NOT
>> mean it's dangerous or that it's not useful with an arbitrary NFS
>> server
>
> We should definitely have clear documentation, but despite that, in
> practice lots of people *will* be surprised when permissions are
> enforced differently after copy-up, and those surprises may well have
> unpleasant implications.

Permissions are enforced exactly the same before and after copy-up.
That's one of the good points in doing the permission checks locally.

That "cp -a /nfs/remotedir /tmp/localdir" example is almost exactly
equivalent to:

  mount -t overlay -olowerdir=/nfs/remotedir,upperdir=/tmp/upper,...
/tmp/localdir

except the copy is delayed until modification.

Thanks,
Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[bfields]

On Fri, Jun 01, 2018 at 04:00:22PM +0200, Miklos Szeredi wrote:
> On Fri, Jun 1, 2018 at 3:50 PM, bfields@fieldses.org
> <bfields@fieldses.org> wrote:
> > On Fri, Jun 01, 2018 at 03:32:59PM +0200, Miklos Szeredi wrote:
> >> How do you define "safely"?
> >>
> >> Is it safe for root to do
> >>
> >>   cp -a /nfs/remotedir /tmp/localdir
> >>
> >> ?
> >>
> >> That's essentially what an overlayfs mount with an NFS layer does with
> >> respect to access permissions:
> >>
> >>  - remote files are not modifiable to anyone, unless server allows
> >>
> >>  - remote files *readable to root* will provide access based on local DAC check.
> >>
> >> Does that need to be made clear in the docs?  Surely.  But it does NOT
> >> mean it's dangerous or that it's not useful with an arbitrary NFS
> >> server
> >
> > We should definitely have clear documentation, but despite that, in
> > practice lots of people *will* be surprised when permissions are
> > enforced differently after copy-up, and those surprises may well have
> > unpleasant implications.
> 
> Permissions are enforced exactly the same before and after copy-up.
> That's one of the good points in doing the permission checks locally.

Whoops, sorry, I missed that.  So you always read owners and mode bits
out of the cached inode and used those to check permissions instead of
calling access?

That still sounds pretty confusing.  E.g. if the server's squashing root
to a user without permission to read a file, you'll pass local
permission checks, but the success a given read may actually depend on
whether the data's already cached?  I feel like I still must not
understand something.  Sorry if I'm making these threads repeat
themselves....

--b.

> 
> That "cp -a /nfs/remotedir /tmp/localdir" example is almost exactly
> equivalent to:
> 
>   mount -t overlay -olowerdir=/nfs/remotedir,upperdir=/tmp/upper,...
> /tmp/localdir
> 
> except the copy is delayed until modification.
> 
> Thanks,
> Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

On Fri, Jun 1, 2018 at 4:26 PM, bfields@fieldses.org
<bfields@fieldses.org> wrote:
> On Fri, Jun 01, 2018 at 04:00:22PM +0200, Miklos Szeredi wrote:
>> On Fri, Jun 1, 2018 at 3:50 PM, bfields@fieldses.org
>> <bfields@fieldses.org> wrote:
>> > On Fri, Jun 01, 2018 at 03:32:59PM +0200, Miklos Szeredi wrote:
>> >> How do you define "safely"?
>> >>
>> >> Is it safe for root to do
>> >>
>> >>   cp -a /nfs/remotedir /tmp/localdir
>> >>
>> >> ?
>> >>
>> >> That's essentially what an overlayfs mount with an NFS layer does with
>> >> respect to access permissions:
>> >>
>> >>  - remote files are not modifiable to anyone, unless server allows
>> >>
>> >>  - remote files *readable to root* will provide access based on local DAC check.
>> >>
>> >> Does that need to be made clear in the docs?  Surely.  But it does NOT
>> >> mean it's dangerous or that it's not useful with an arbitrary NFS
>> >> server
>> >
>> > We should definitely have clear documentation, but despite that, in
>> > practice lots of people *will* be surprised when permissions are
>> > enforced differently after copy-up, and those surprises may well have
>> > unpleasant implications.
>>
>> Permissions are enforced exactly the same before and after copy-up.
>> That's one of the good points in doing the permission checks locally.
>
> Whoops, sorry, I missed that.  So you always read owners and mode bits
> out of the cached inode and used those to check permissions instead of
> calling access?
>
> That still sounds pretty confusing.  E.g. if the server's squashing root
> to a user without permission to read a file, you'll pass local
> permission checks, but the success a given read may actually depend on
> whether the data's already cached?

You have a point there.  I think current code can be inconsistent like
that.  But that's only because it doesn't stack file operations.
Stacking f_ops is now queued up for 4.18, which means that *all* calls
into underlying layers should be with the same creds (those of the
mounting task), regardless of the creds of the task performing the
operation.

So if NFS server is denying read to mounter (because of root squashing
or for other reason), then that file will not be accessible from
overlayfs by anyone and will not be in the cache either.  If access to
mounter is allowed, then the access will be based on local DAC.

Look at ovl_permission(), I think it pretty clearly describes this model.

Thanks,
Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[bfields]

On Fri, Jun 01, 2018 at 04:43:51PM +0200, Miklos Szeredi wrote:
> On Fri, Jun 1, 2018 at 4:26 PM, bfields@fieldses.org
> <bfields@fieldses.org> wrote:
> > On Fri, Jun 01, 2018 at 04:00:22PM +0200, Miklos Szeredi wrote:
> >> On Fri, Jun 1, 2018 at 3:50 PM, bfields@fieldses.org
> >> <bfields@fieldses.org> wrote:
> >> > On Fri, Jun 01, 2018 at 03:32:59PM +0200, Miklos Szeredi wrote:
> >> >> How do you define "safely"?
> >> >>
> >> >> Is it safe for root to do
> >> >>
> >> >>   cp -a /nfs/remotedir /tmp/localdir
> >> >>
> >> >> ?
> >> >>
> >> >> That's essentially what an overlayfs mount with an NFS layer does with
> >> >> respect to access permissions:
> >> >>
> >> >>  - remote files are not modifiable to anyone, unless server allows
> >> >>
> >> >>  - remote files *readable to root* will provide access based on local DAC check.
> >> >>
> >> >> Does that need to be made clear in the docs?  Surely.  But it does NOT
> >> >> mean it's dangerous or that it's not useful with an arbitrary NFS
> >> >> server
> >> >
> >> > We should definitely have clear documentation, but despite that, in
> >> > practice lots of people *will* be surprised when permissions are
> >> > enforced differently after copy-up, and those surprises may well have
> >> > unpleasant implications.
> >>
> >> Permissions are enforced exactly the same before and after copy-up.
> >> That's one of the good points in doing the permission checks locally.
> >
> > Whoops, sorry, I missed that.  So you always read owners and mode bits
> > out of the cached inode and used those to check permissions instead of
> > calling access?
> >
> > That still sounds pretty confusing.  E.g. if the server's squashing root
> > to a user without permission to read a file, you'll pass local
> > permission checks, but the success a given read may actually depend on
> > whether the data's already cached?
> 
> You have a point there.  I think current code can be inconsistent like
> that.  But that's only because it doesn't stack file operations.
> Stacking f_ops is now queued up for 4.18, which means that *all* calls
> into underlying layers should be with the same creds (those of the
> mounting task), regardless of the creds of the task performing the
> operation.
> 
> So if NFS server is denying read to mounter (because of root squashing
> or for other reason), then that file will not be accessible from
> overlayfs by anyone and will not be in the cache either.  If access to
> mounter is allowed, then the access will be based on local DAC.
> 
> Look at ovl_permission(), I think it pretty clearly describes this model.

Thanks!  Uh, so generic_permission is the thing that just does the usual
mode/acl checks on the in-core inode, and inode_permission is the one
that also calls into the filesystem?

But I'm still a little confused--if I'm reading right, "realinode" is
the lower inode before copyup, and the upper inode after, so can't
inode_permission(realinode, mask) return different results before and
after copyup?

--b.

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

On Fri, Jun 1, 2018 at 6:08 PM, bfields@fieldses.org
<bfields@fieldses.org> wrote:
> On Fri, Jun 01, 2018 at 04:43:51PM +0200, Miklos Szeredi wrote:
>> On Fri, Jun 1, 2018 at 4:26 PM, bfields@fieldses.org
>> <bfields@fieldses.org> wrote:
>> > On Fri, Jun 01, 2018 at 04:00:22PM +0200, Miklos Szeredi wrote:
>> >> On Fri, Jun 1, 2018 at 3:50 PM, bfields@fieldses.org
>> >> <bfields@fieldses.org> wrote:
>> >> > On Fri, Jun 01, 2018 at 03:32:59PM +0200, Miklos Szeredi wrote:
>> >> >> How do you define "safely"?
>> >> >>
>> >> >> Is it safe for root to do
>> >> >>
>> >> >>   cp -a /nfs/remotedir /tmp/localdir
>> >> >>
>> >> >> ?
>> >> >>
>> >> >> That's essentially what an overlayfs mount with an NFS layer does with
>> >> >> respect to access permissions:
>> >> >>
>> >> >>  - remote files are not modifiable to anyone, unless server allows
>> >> >>
>> >> >>  - remote files *readable to root* will provide access based on local DAC check.
>> >> >>
>> >> >> Does that need to be made clear in the docs?  Surely.  But it does NOT
>> >> >> mean it's dangerous or that it's not useful with an arbitrary NFS
>> >> >> server
>> >> >
>> >> > We should definitely have clear documentation, but despite that, in
>> >> > practice lots of people *will* be surprised when permissions are
>> >> > enforced differently after copy-up, and those surprises may well have
>> >> > unpleasant implications.
>> >>
>> >> Permissions are enforced exactly the same before and after copy-up.
>> >> That's one of the good points in doing the permission checks locally.
>> >
>> > Whoops, sorry, I missed that.  So you always read owners and mode bits
>> > out of the cached inode and used those to check permissions instead of
>> > calling access?
>> >
>> > That still sounds pretty confusing.  E.g. if the server's squashing root
>> > to a user without permission to read a file, you'll pass local
>> > permission checks, but the success a given read may actually depend on
>> > whether the data's already cached?
>>
>> You have a point there.  I think current code can be inconsistent like
>> that.  But that's only because it doesn't stack file operations.
>> Stacking f_ops is now queued up for 4.18, which means that *all* calls
>> into underlying layers should be with the same creds (those of the
>> mounting task), regardless of the creds of the task performing the
>> operation.
>>
>> So if NFS server is denying read to mounter (because of root squashing
>> or for other reason), then that file will not be accessible from
>> overlayfs by anyone and will not be in the cache either.  If access to
>> mounter is allowed, then the access will be based on local DAC.
>>
>> Look at ovl_permission(), I think it pretty clearly describes this model.
>
> Thanks!  Uh, so generic_permission is the thing that just does the usual
> mode/acl checks on the in-core inode, and inode_permission is the one
> that also calls into the filesystem?

Right.

> But I'm still a little confused--if I'm reading right, "realinode" is
> the lower inode before copyup, and the upper inode after, so can't
> inode_permission(realinode, mask) return different results before and
> after copyup?

Theoretically, yes.  Not in any sane setup, though.

The inode_permission() checks on realinode are for making sure the
mounter cannot gain undue privileges (will be especially important
with userns mounts).

Thanks,
Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[bfields]

On Fri, Jun 01, 2018 at 07:02:20PM +0200, Miklos Szeredi wrote:
> On Fri, Jun 1, 2018 at 6:08 PM, bfields@fieldses.org
> <bfields@fieldses.org> wrote:
> > On Fri, Jun 01, 2018 at 04:43:51PM +0200, Miklos Szeredi wrote:
> >> Look at ovl_permission(), I think it pretty clearly describes this model.
> >
> > Thanks!  Uh, so generic_permission is the thing that just does the usual
> > mode/acl checks on the in-core inode, and inode_permission is the one
> > that also calls into the filesystem?
> 
> Right.
> 
> > But I'm still a little confused--if I'm reading right, "realinode" is
> > the lower inode before copyup, and the upper inode after, so can't
> > inode_permission(realinode, mask) return different results before and
> > after copyup?
> 
> Theoretically, yes.  Not in any sane setup, though.

If root squashing is enabled and you mount as root, then it will change.

That's not an unlikely case, it's pretty much the default.

--b.

> 
> The inode_permission() checks on realinode are for making sure the
> mounter cannot gain undue privileges (will be especially important
> with userns mounts).

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

On Fri, Jun 1, 2018 at 7:43 PM, bfields@fieldses.org
<bfields@fieldses.org> wrote:
> On Fri, Jun 01, 2018 at 07:02:20PM +0200, Miklos Szeredi wrote:
>> On Fri, Jun 1, 2018 at 6:08 PM, bfields@fieldses.org
>> <bfields@fieldses.org> wrote:
>> > On Fri, Jun 01, 2018 at 04:43:51PM +0200, Miklos Szeredi wrote:
>> >> Look at ovl_permission(), I think it pretty clearly describes this model.
>> >
>> > Thanks!  Uh, so generic_permission is the thing that just does the usual
>> > mode/acl checks on the in-core inode, and inode_permission is the one
>> > that also calls into the filesystem?
>>
>> Right.
>>
>> > But I'm still a little confused--if I'm reading right, "realinode" is
>> > the lower inode before copyup, and the upper inode after, so can't
>> > inode_permission(realinode, mask) return different results before and
>> > after copyup?
>>
>> Theoretically, yes.  Not in any sane setup, though.
>
> If root squashing is enabled and you mount as root, then it will change.
>
> That's not an unlikely case, it's pretty much the default.

Let's see: root squashing will change root creds to nobody's creds, right?

That results in a weird situation, where user foo is trying to access
a file owned by foo, but which doesn't have read permission for
"other" will not be able to perform a read on that file.  In fact, no
user will be able to read that file, including root.   Copying up the
file will also fail, since that requires read permission.

So for that case it's not true that permission will change, since
copy-up won't be possible.

That leaves the case where no read or write permissions are involved,
which is execute.  I think we should just mask that out from the
inode_permission() check.  Makes no sense to ask underlying filesystem
about execute permission.   With that we'll have consistent
permissions before and after copy-up.  Right?

Thanks,
Miklos

Re: nfs4_acl restricts copy_up in overlayfs

[bfields]

On Fri, Jun 01, 2018 at 09:14:38PM +0200, Miklos Szeredi wrote:
> On Fri, Jun 1, 2018 at 7:43 PM, bfields@fieldses.org
> <bfields@fieldses.org> wrote:
> > On Fri, Jun 01, 2018 at 07:02:20PM +0200, Miklos Szeredi wrote:
> >> On Fri, Jun 1, 2018 at 6:08 PM, bfields@fieldses.org
> >> <bfields@fieldses.org> wrote:
> >> > On Fri, Jun 01, 2018 at 04:43:51PM +0200, Miklos Szeredi wrote:
> >> >> Look at ovl_permission(), I think it pretty clearly describes this model.
> >> >
> >> > Thanks!  Uh, so generic_permission is the thing that just does the usual
> >> > mode/acl checks on the in-core inode, and inode_permission is the one
> >> > that also calls into the filesystem?
> >>
> >> Right.
> >>
> >> > But I'm still a little confused--if I'm reading right, "realinode" is
> >> > the lower inode before copyup, and the upper inode after, so can't
> >> > inode_permission(realinode, mask) return different results before and
> >> > after copyup?
> >>
> >> Theoretically, yes.  Not in any sane setup, though.
> >
> > If root squashing is enabled and you mount as root, then it will change.
> >
> > That's not an unlikely case, it's pretty much the default.
> 
> Let's see: root squashing will change root creds to nobody's creds, right?
> 
> That results in a weird situation, where user foo is trying to access
> a file owned by foo, but which doesn't have read permission for
> "other" will not be able to perform a read on that file.  In fact, no
> user will be able to read that file, including root.   Copying up the
> file will also fail, since that requires read permission.
> 
> So for that case it's not true that permission will change, since
> copy-up won't be possible.

Fair enough.  That's still pretty weird behavior.

Arguably if you're going to do something different here then maybe it's
good for the difference to manifest in a way that's really obvious in
common cases, so people don't just overlook it.

> That leaves the case where no read or write permissions are involved,
> which is execute.  I think we should just mask that out from the
> inode_permission() check.  Makes no sense to ask underlying filesystem
> about execute permission.

I suppose so.

> With that we'll have consistent permissions before and after copy-up.
> Right?

Hm.  If inode_permission(realinode, mask) changes across copy-up: 

	- if the difference is in execute, you're telling me we'll
	  ignore that.
	- if it changes from denying to allowing read, you don't care
	  since that will prevent the copy up in the first place.
	- if it changes from denying to allowing write, that has no
	  effect since you only care about read permission for copyup in
	  the case someone requests write permission.  (Hm, the special
	  file case should be weird.  I guess those just don't get
	  copied up?  Still I think people will be surprised by
	  permission failures here.)
	- if it changes from allowing read or write to denying--then
	  we're no longer talking about root, assuming the permission
	  check on the copied-up inode wouldn't fail for root.  We don't
	  currently allow non-root to mount NFS, but there are people
	  that would like to see that change.

--b.

Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi]

On Sat, Jun 2, 2018 at 2:50 AM, bfields@fieldses.org
<bfields@fieldses.org> wrote:
> On Fri, Jun 01, 2018 at 09:14:38PM +0200, Miklos Szeredi wrote:
>> On Fri, Jun 1, 2018 at 7:43 PM, bfields@fieldses.org
>> <bfields@fieldses.org> wrote:
>> > On Fri, Jun 01, 2018 at 07:02:20PM +0200, Miklos Szeredi wrote:
>> >> On Fri, Jun 1, 2018 at 6:08 PM, bfields@fieldses.org
>> >> <bfields@fieldses.org> wrote:
>> >> > On Fri, Jun 01, 2018 at 04:43:51PM +0200, Miklos Szeredi wrote:
>> >> >> Look at ovl_permission(), I think it pretty clearly describes this model.
>> >> >
>> >> > Thanks!  Uh, so generic_permission is the thing that just does the usual
>> >> > mode/acl checks on the in-core inode, and inode_permission is the one
>> >> > that also calls into the filesystem?
>> >>
>> >> Right.
>> >>
>> >> > But I'm still a little confused--if I'm reading right, "realinode" is
>> >> > the lower inode before copyup, and the upper inode after, so can't
>> >> > inode_permission(realinode, mask) return different results before and
>> >> > after copyup?
>> >>
>> >> Theoretically, yes.  Not in any sane setup, though.
>> >
>> > If root squashing is enabled and you mount as root, then it will change.
>> >
>> > That's not an unlikely case, it's pretty much the default.
>>
>> Let's see: root squashing will change root creds to nobody's creds, right?
>>
>> That results in a weird situation, where user foo is trying to access
>> a file owned by foo, but which doesn't have read permission for
>> "other" will not be able to perform a read on that file.  In fact, no
>> user will be able to read that file, including root.   Copying up the
>> file will also fail, since that requires read permission.
>>
>> So for that case it's not true that permission will change, since
>> copy-up won't be possible.
>
> Fair enough.  That's still pretty weird behavior.
>
> Arguably if you're going to do something different here then maybe it's
> good for the difference to manifest in a way that's really obvious in
> common cases, so people don't just overlook it.
>
>> That leaves the case where no read or write permissions are involved,
>> which is execute.  I think we should just mask that out from the
>> inode_permission() check.  Makes no sense to ask underlying filesystem
>> about execute permission.
>
> I suppose so.
>
>> With that we'll have consistent permissions before and after copy-up.
>> Right?
>
> Hm.  If inode_permission(realinode, mask) changes across copy-up:
>
>         - if the difference is in execute, you're telling me we'll
>           ignore that.
>         - if it changes from denying to allowing read, you don't care
>           since that will prevent the copy up in the first place.
>         - if it changes from denying to allowing write, that has no
>           effect since you only care about read permission for copyup in
>           the case someone requests write permission.  (Hm, the special
>           file case should be weird.  I guess those just don't get
>           copied up?  Still I think people will be surprised by
>           permission failures here.)

Special file can get copied up on metadata change.  We shoudln't ask
server at all for permissions in this case.  That would be consistent
with the "cp -a" model.

>         - if it changes from allowing read or write to denying--then
>           we're no longer talking about root, assuming the permission
>           check on the copied-up inode wouldn't fail for root.  We don't
>           currently allow non-root to mount NFS, but there are people
>           that would like to see that change.

The "cp -a" model should work even for userns unprivileged mounts.  We
do assume a certain sanity with setups: I'm sure someone could come up
with a setup (e.g. with selinux) where weirdness happens after
copy-up.

Thanks,
Miklos



>
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html