summaryrefslogtreecommitdiff
path: root/include/linux/dynamic_queue_limits.h
diff options
context:
space:
mode:
authorMiklos Szeredi <mszeredi@redhat.com>2016-12-06 16:18:45 +0100
committerBen Hutchings <ben@decadent.org.uk>2017-02-23 03:54:43 +0000
commita4ab1eeb4f60563209664142185a4969c703f02d (patch)
treecc1f1d6c2dbdce6d48d40081caa2e0016c7e3d31 /include/linux/dynamic_queue_limits.h
parentdd613d3308c5d7223746b955317fd5f825074419 (diff)
fuse: fix clearing suid, sgid for chown()
commit c01638f5d919728f565bf8b5e0a6a159642df0d9 upstream. Basically, the pjdfstests set the ownership of a file to 06555, and then chowns it (as root) to a new uid/gid. Prior to commit a09f99eddef4 ("fuse: fix killing s[ug]id in setattr"), fuse would send down a setattr with both the uid/gid change and a new mode. Now, it just sends down the uid/gid change. Technically this is NOTABUG, since POSIX doesn't _require_ that we clear these bits for a privileged process, but Linux (wisely) has done that and I think we don't want to change that behavior here. This is caused by the use of should_remove_suid(), which will always return 0 when the process has CAP_FSETID. In fact we really don't need to be calling should_remove_suid() at all, since we've already been indicated that we should remove the suid, we just don't want to use a (very) stale mode for that. This patch should fix the above as well as simplify the logic. Reported-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Fixes: a09f99eddef4 ("fuse: fix killing s[ug]id in setattr") Reviewed-by: Jeff Layton <jlayton@redhat.com> [bwh: Backported to 3.16: adjust context, indentation] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Diffstat (limited to 'include/linux/dynamic_queue_limits.h')
0 files changed, 0 insertions, 0 deletions