acl: move idmapping handling into posix_acl_xattr_set()
The uapi POSIX ACL struct passed through the value argument during
setxattr() contains {g,u}id values encoded via ACL_{GROUP,USER} entries
that should actually be stored in the form of k{g,u}id_t (See [1] for a
long explanation of the issue.).
In 0c5fd887d2 ("acl: move idmapped mount fixup into vfs_{g,s}etxattr()")
we took the mount's idmapping into account in order to let overlayfs
handle POSIX ACLs on idmapped layers correctly. The fixup is currently
performed directly in vfs_setxattr() which piles on top of the earlier
hackiness by handling the mount's idmapping and stuff the vfs{g,u}id_t
values into the uapi struct as well. While that is all correct and works
fine it's just ugly.
Now that we have introduced vfs_make_posix_acl() earlier move handling
idmapped mounts out of vfs_setxattr() and into the POSIX ACL handler
where it belongs.
Note that we also need to call vfs_make_posix_acl() for EVM which
interpretes POSIX ACLs during security_inode_setxattr(). Leave them a
longer comment for future reference.
All filesystems that support idmapped mounts via FS_ALLOW_IDMAP use the
standard POSIX ACL xattr handlers and are covered by this change. This
includes overlayfs which simply calls vfs_{g,s}etxattr().
The following filesystems use custom POSIX ACL xattr handlers: 9p, cifs,
ecryptfs, and ntfs3 (and overlayfs but we've covered that in the paragraph
above) and none of them support idmapped mounts yet.
Link: https://lore.kernel.org/all/20220801145520.1532837-1-brauner@kernel.org/ [1]
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Reviewed-by: Seth Forshee (DigitalOcean) <sforshee@kernel.org>
This commit is contained in:
parent
6b70fe0601
commit
52edb4080e
4 changed files with 25 additions and 56 deletions
|
|
@ -457,10 +457,21 @@ static int evm_xattr_acl_change(struct user_namespace *mnt_userns,
|
|||
int rc;
|
||||
|
||||
/*
|
||||
* user_ns is not relevant here, ACL_USER/ACL_GROUP don't have impact
|
||||
* on the inode mode (see posix_acl_equiv_mode()).
|
||||
* An earlier comment here mentioned that the idmappings for
|
||||
* ACL_{GROUP,USER} don't matter since EVM is only interested in the
|
||||
* mode stored as part of POSIX ACLs. Nonetheless, if it must translate
|
||||
* from the uapi POSIX ACL representation to the VFS internal POSIX ACL
|
||||
* representation it should do so correctly. There's no guarantee that
|
||||
* we won't change POSIX ACLs in a way that ACL_{GROUP,USER} matters
|
||||
* for the mode at some point and it's difficult to keep track of all
|
||||
* the LSM and integrity modules and what they do to POSIX ACLs.
|
||||
*
|
||||
* Frankly, EVM shouldn't try to interpret the uapi struct for POSIX
|
||||
* ACLs it received. It requires knowledge that only the VFS is
|
||||
* guaranteed to have.
|
||||
*/
|
||||
acl = posix_acl_from_xattr(&init_user_ns, xattr_value, xattr_value_len);
|
||||
acl = vfs_set_acl_prepare(mnt_userns, i_user_ns(inode),
|
||||
xattr_value, xattr_value_len);
|
||||
if (IS_ERR_OR_NULL(acl))
|
||||
return 1;
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue