On Mon, Jul 12, 2021 at 01:47:59PM -0400, Vivek Goyal wrote: > On Mon, Jul 12, 2021 at 11:41:06AM -0400, J. Bruce Fields wrote: > > Looks like 0xd is what the server returns to access on a device node > > with mode bits rw- for the caller. > > > > Commit c11d7fd1b317 "nfsd: take xattr bits into account for permission > > checks" added the ACCESS_X* bits for regular files and directories but > > not others. > > > > But you don't want to determine permission from the mode bits anyway, > > you want it to depend on the owner, > > Thinking more about this part. Current implementation of my patch is > effectively doing both the checks. It checks that you are owner or > have CAP_FOWNER in xattr_permission() and then goes on to call > inode_permission(). And that means file mode bits will also play a > role. If caller does not have write permission on the file, it will > be denied setxattr(). > > If I don't call inode_permission(), and just return 0 right away for > file owner (for symlinks and special files), then just being owner > is enough to write user.* xattr. And then even security modules will > not get a chance to block that operation. IOW, if you are owner of > a symlink or special file, you can write as many user.* xattr as you > like and except quota does not look like anything else can block > it. I am wondering if this approach is ok? Yeah, I'd expect security modules to get a say, and I wouldn't expect mode bits on device nodes to be useful for deciding whether it makes sense for xattrs to be readable or writeable. But, I don't really know. Do we have any other use cases besides this case of storing security labels in user xattrs? --b.
