1. 27 Jan, 2016 1 commit
    • Trond Myklebust's avatar
      NFSv4: Don't perform cached access checks before we've OPENed the file · 9ddd9c61
      Trond Myklebust authored
      commit 762674f8 upstream.
      
      Donald Buczek reports that a nfs4 client incorrectly denies
      execute access based on outdated file mode (missing 'x' bit).
      After the mode on the server is 'fixed' (chmod +x) further execution
      attempts continue to fail, because the nfs ACCESS call updates
      the access parameter but not the mode parameter or the mode in
      the inode.
      
      The root cause is ultimately that the VFS is calling may_open()
      before the NFS client has a chance to OPEN the file and hence revalidate
      the access and attribute caches.
      
      Al Viro suggests:
      >>> Make nfs_permission() relax the checks when it sees MAY_OPEN, if you know
      >>> that things will be caught by server anyway?
      >>
      >> That can work as long as we're guaranteed that everything that calls
      >> inode_permission() with MAY_OPEN on a regular file will also follow up
      >> with a vfs_open() or dentry_open() on success. Is this always the
      >> case?
      >
      > 1) in do_tmpfile(), followed by do_dentry_open() (not reachable by NFS since
      > it doesn't have ->tmpfile() instance anyway)
      >
      > 2) in atomic_open(), after the call of ->atomic_open() has succeeded.
      >
      > 3) in do_last(), followed on success by vfs_open()
      >
      > That's all.  All calls of inode_permission() that get MAY_OPEN come from
      > may_open(), and there's no other callers of that puppy.
      Reported-by: default avatarDonald Buczek <buczek@molgen.mpg.de>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=109771
      Link: http://lkml.kernel.org/r/1451046656-26319-1-git-send-email-buczek@molgen.mpg.de
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9ddd9c61
  2. 26 Jan, 2016 39 commits