]> rtime.felk.cvut.cz Git - linux-imx.git/commit
nfsd: allow owner_override only for regular files
authorJ. Bruce Fields <bfields@redhat.com>
Wed, 6 Jun 2012 16:12:57 +0000 (12:12 -0400)
committerJ. Bruce Fields <bfields@redhat.com>
Tue, 10 Jul 2012 20:41:35 +0000 (16:41 -0400)
commitd91d0b569044ab366895d587d4811b154dd7d7f5
tree3b1877f782ad3aa9345637c454b4b298a14da0f7
parent74dbafaf5d84b5187e50dbe82442ec8df66d55b3
nfsd: allow owner_override only for regular files

We normally allow the owner of a file to override permissions checks on
IO operations, since:
- the client will take responsibility for doing an access check
  on open;
- the permission checks offer no protection against malicious
  clients--if they can authenticate as the file's owner then
  they can always just change its permissions;
- checking permission on each IO operation breaks the usual
  posix rule that permission is checked only on open.

However, we've never allowed the owner to override permissions on
readdir operations, even though the above logic would also apply to
directories.  I've never heard of this causing a problem, probably
because a) simultaneously opening and creating a directory (with
restricted mode) isn't possible, and b) opening a directory, then
chmod'ing it, is rare.

Our disallowal of owner-override on directories appears to be an
accident, though--the readdir itself succeeds, and then we fail just
because lookup_one_len() calls in our filldir methods fail.

I'm not sure what the easiest fix for that would be.  For now, just make
this behavior obvious by denying the override right at the start.

This also fixes some odd v4 behavior: with the rdattr_error attribute
requested, it would perform the readdir but return an ACCES error with
each entry.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
fs/nfsd/vfs.c