Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi <miklos@szeredi.hu>]

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