]> git.baikalelectronics.ru Git - kernel.git/commit
knfsd: clear both setuid and setgid whenever a chown is done
authorJeff Layton <jlayton@redhat.com>
Wed, 16 Apr 2008 20:28:47 +0000 (16:28 -0400)
committerJ. Bruce Fields <bfields@citi.umich.edu>
Wed, 23 Apr 2008 20:13:43 +0000 (16:13 -0400)
commit49f51c42e644e7fe836f0dee1d6955b0d973b2a6
tree3d62ce9e370dfe62e986ab44710262991a2ad2e1
parent1629fca6ec9ac05e65273eceb051708787fd234f
knfsd: clear both setuid and setgid whenever a chown is done

Currently, knfsd only clears the setuid bit if the owner of a file is
changed on a SETATTR call, and only clears the setgid bit if the group
is changed. POSIX says this in the spec for chown():

    "If the specified file is a regular file, one or more of the
     S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are set, and the
     process does not have appropriate privileges, the set-user-ID
     (S_ISUID) and set-group-ID (S_ISGID) bits of the file mode shall
     be cleared upon successful return from chown()."

If I'm reading this correctly, then knfsd is doing this wrong. It should
be clearing both the setuid and setgid bit on any SETATTR that changes
the uid or gid. This wasn't really as noticable before, but now that the
ATTR_KILL_S*ID bits are a no-op for the NFS client, it's more evident.

This patch corrects the nfsd_setattr logic so that this occurs. It also
does a bit of cleanup to the function.

There is also one small behavioral change. If a SETATTR call comes in
that changes the uid/gid and the mode, then we now only clear the setgid
bit if the group execute bit isn't set. The setgid bit without a group
execute bit signifies mandatory locking and we likely don't want to
clear the bit in that case. Since there is no call in POSIX that should
generate a SETATTR call like this, then this should rarely happen, but
it's worth noting.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
fs/nfsd/vfs.c