summaryrefslogtreecommitdiff
path: root/fs/ioctl.c
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2017-04-22 03:14:32 +0300
committerEric W. Biederman <ebiederm@xmission.com>2018-05-24 20:03:31 +0300
commitb1d749c5c34112fab5902c43b2a37a0ba1e5f0f1 (patch)
tree4e0c26b4c2b9ee8db3306f5d70df7d52a2cd4a0f /fs/ioctl.c
parentbc6155d1326092f4c29fe05a32b614249620d88e (diff)
downloadlinux-b1d749c5c34112fab5902c43b2a37a0ba1e5f0f1.tar.xz
capabilities: Allow privileged user in s_user_ns to set security.* xattrs
A privileged user in s_user_ns will generally have the ability to manipulate the backing store and insert security.* xattrs into the filesystem directly. Therefore the kernel must be prepared to handle these xattrs from unprivileged mounts, and it makes little sense for commoncap to prevent writing these xattrs to the filesystem. The capability and LSM code have already been updated to appropriately handle xattrs from unprivileged mounts, so it is safe to loosen this restriction on setting xattrs. The exception to this logic is that writing xattrs to a mounted filesystem may also cause the LSM inode_post_setxattr or inode_setsecurity callbacks to be invoked. SELinux will deny the xattr update by virtue of applying mountpoint labeling to unprivileged userns mounts, and Smack will deny the writes for any user without global CAP_MAC_ADMIN, so loosening the capability check in commoncap is safe in this respect as well. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Serge Hallyn <serge@hallyn.com> Acked-by: Christian Brauner <christian@brauner.io> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Diffstat (limited to 'fs/ioctl.c')
0 files changed, 0 insertions, 0 deletions