Re: NFSv3 may inappropriately return EPERM for fsetxattr

[Bruce Fields <bfields@fieldses.org>]

On Tue, Aug 14, 2018 at 07:03:14PM +1000, NeilBrown wrote:
> On Mon, Aug 13 2018, NeilBrown wrote:
> 
> > On Sun, Aug 12 2018, Bruce Fields wrote:
> >> OK, so not too important.  Still, it sounds like
> >> inode_owner_or_capable() is something people expect to work for any
> >> filesystem, so I wonder if there's a way to do that.  Or at least
> >> disable it.
> >
> > We could add a new flag - MAY_OWN (or something) - to the flags
> > recognised by inode_permission() and i_op->permission().
> >
> > If ->permission isn't set, inode_permission() uses
> > inode_owner_or_capable().
> > If it is, it gets to call that, or do whatever is appropriate.
> >
> > Is this flag the same as NFS_MAY_OWNER_OVERRIDE or not....??
> >
> 
> Pursuing this thought...
>   NFSD_MAY_OWNER_OVERRIDE means "an operation is requested which
>    may always be performed by the owner of the file, even if they
>    don't have explicit permission via DAC setting."
> 
> I think this is a reasonable description of how inode_owner_or_capable()
> is used.  It is sometimes used on its own, where there is no permission
> but that is relevant such as O_NOATIME or set_posix_acl(), or is used
> as a precursor to and inode_permission() check, as in notify_change().
> 
> The biggest difference is that NFSD_MAY_OWNER_OVERRIDE does have the
> "or_capable".
> As nfsd drops CAP_FOWNER, and the extra test won't hurt it.
> 
> So I now think that a good solution to this problem would be to hoist
> NFSD_MAY_OWNER_OVERRIDE into the VFS and change inode_permission() and
> various i_op->permission functions to handle it.
> 
> All we need is a good name....
>   MAY_BY_OWNER  ???
>   MAY_IF_OWNER
>   MAY_BE_OWNER ???
> 
> MAY_READ means "may I please read this file".  The flag needs to say
> "may I act as the owner of this file", so
>   MAY_ACT_AS_OWNER ????

It's still a little different from the other permission bits in that I
believe

	permission(., READ|WRITE)
		== permission(., READ) && permission(., WRITE)

but

	permission(., READ|OWNER_OVERRIDE)
		== permission(., READ) || permission(., OWNER_OVERRIDE)

?

Anyway, naming aside....  I don't know, sounds like it might work?
Honestly I'm not completely sure I understand the proposal.

--b.