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 ???? Thought? NeilBrown
Attachment:
signature.asc
Description: PGP signature
