1. 25 10月, 2013 1 次提交
  2. 24 7月, 2013 1 次提交
    • H
      nfsd: nfsd_open: when dentry_open returns an error do not propagate as struct file · e4daf1ff
      Harshula Jayasuriya 提交于
      The following call chain:
      ------------------------------------------------------------
      nfs4_get_vfs_file
      - nfsd_open
        - dentry_open
          - do_dentry_open
            - __get_file_write_access
              - get_write_access
                - return atomic_inc_unless_negative(&inode->i_writecount) ? 0 : -ETXTBSY;
      ------------------------------------------------------------
      
      can result in the following state:
      ------------------------------------------------------------
      struct nfs4_file {
      ...
        fi_fds = {0xffff880c1fa65c80, 0xffffffffffffffe6, 0x0},
        fi_access = {{
            counter = 0x1
          }, {
            counter = 0x0
          }},
      ...
      ------------------------------------------------------------
      
      1) First time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
      NULL, hence nfsd_open() is called where we get status set to an error
      and fp->fi_fds[O_WRONLY] to -ETXTBSY. Thus we do not reach
      nfs4_file_get_access() and fi_access[O_WRONLY] is not incremented.
      
      2) Second time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
      NOT NULL (-ETXTBSY), so nfsd_open() is NOT called, but
      nfs4_file_get_access() IS called and fi_access[O_WRONLY] is incremented.
      Thus we leave a landmine in the form of the nfs4_file data structure in
      an incorrect state.
      
      3) Eventually, when __nfs4_file_put_access() is called it finds
      fi_access[O_WRONLY] being non-zero, it decrements it and calls
      nfs4_file_put_fd() which tries to fput -ETXTBSY.
      ------------------------------------------------------------
      ...
           [exception RIP: fput+0x9]
           RIP: ffffffff81177fa9  RSP: ffff88062e365c90  RFLAGS: 00010282
           RAX: ffff880c2b3d99cc  RBX: ffff880c2b3d9978  RCX: 0000000000000002
           RDX: dead000000100101  RSI: 0000000000000001  RDI: ffffffffffffffe6
           RBP: ffff88062e365c90   R8: ffff88041fe797d8   R9: ffff88062e365d58
           R10: 0000000000000008  R11: 0000000000000000  R12: 0000000000000001
           R13: 0000000000000007  R14: 0000000000000000  R15: 0000000000000000
           ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
        #9 [ffff88062e365c98] __nfs4_file_put_access at ffffffffa0562334 [nfsd]
       #10 [ffff88062e365cc8] nfs4_file_put_access at ffffffffa05623ab [nfsd]
       #11 [ffff88062e365ce8] free_generic_stateid at ffffffffa056634d [nfsd]
       #12 [ffff88062e365d18] release_open_stateid at ffffffffa0566e4b [nfsd]
       #13 [ffff88062e365d38] nfsd4_close at ffffffffa0567401 [nfsd]
       #14 [ffff88062e365d88] nfsd4_proc_compound at ffffffffa0557f28 [nfsd]
       #15 [ffff88062e365dd8] nfsd_dispatch at ffffffffa054543e [nfsd]
       #16 [ffff88062e365e18] svc_process_common at ffffffffa04ba5a4 [sunrpc]
       #17 [ffff88062e365e98] svc_process at ffffffffa04babe0 [sunrpc]
       #18 [ffff88062e365eb8] nfsd at ffffffffa0545b62 [nfsd]
       #19 [ffff88062e365ee8] kthread at ffffffff81090886
       #20 [ffff88062e365f48] kernel_thread at ffffffff8100c14a
      ------------------------------------------------------------
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NHarshula Jayasuriya <harshula@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      e4daf1ff
  3. 29 6月, 2013 2 次提交
  4. 15 5月, 2013 1 次提交
  5. 27 4月, 2013 1 次提交
    • J
      nfsd: fix EXDEV checking in rename · aa387d6c
      J. Bruce Fields 提交于
      We again check for the EXDEV a little later on, so the first check is
      redundant.  This check is also slightly racier, since a badly timed
      eviction from the export cache could leave us with the two fh_export
      pointers pointing to two different cache entries which each refer to the
      same underlying export.
      
      It's better to compare vfsmounts as the later check does, but that
      leaves a minor security hole in the case where the two exports refer to
      two different directories especially if (for example) they have
      different root-squashing options.
      
      So, compare ex_path.dentry too.
      Reported-by: NJoe Habermann <joe.habermann@gmail.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      aa387d6c
  6. 23 3月, 2013 1 次提交
  7. 23 2月, 2013 1 次提交
  8. 13 2月, 2013 1 次提交
    • E
      nfsd: Properly compare and initialize kuids and kgids · 6fab8779
      Eric W. Biederman 提交于
      Use uid_eq(uid, GLOBAL_ROOT_UID) instead of !uid.
      Use gid_eq(gid, GLOBAL_ROOT_GID) instead of !gid.
      Use uid_eq(uid, INVALID_UID) instead of uid == -1
      Use gid_eq(uid, INVALID_GID) instead of gid == -1
      Use uid = GLOBAL_ROOT_UID instead of uid = 0;
      Use gid = GLOBAL_ROOT_GID instead of gid = 0;
      Use !uid_eq(uid1, uid2) instead of uid1 != uid2.
      Use !gid_eq(gid1, gid2) instead of gid1 != gid2.
      Use uid_eq(uid1, uid2) instead of uid1 == uid2.
      
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      6fab8779
  9. 22 12月, 2012 1 次提交
  10. 18 12月, 2012 2 次提交
  11. 11 12月, 2012 1 次提交
    • N
      nfsd: avoid permission checks on EXCLUSIVE_CREATE replay · 7007c90f
      Neil Brown 提交于
      With NFSv4, if we create a file then open it we explicit avoid checking
      the permissions on the file during the open because the fact that we
      created it ensures we should be allow to open it (the create and the
      open should appear to be a single operation).
      
      However if the reply to an EXCLUSIVE create gets lots and the client
      resends the create, the current code will perform the permission check -
      because it doesn't realise that it did the open already..
      
      This patch should fix this.
      
      Note that I haven't actually seen this cause a problem.  I was just
      looking at the code trying to figure out a different EXCLUSIVE open
      related issue, and this looked wrong.
      
      (Fix confirmed with pynfs 4.0 test OPEN4--bfields)
      
      Cc: stable@kernel.org
      Signed-off-by: NNeilBrown <neilb@suse.de>
      [bfields: use OWNER_OVERRIDE and update for 4.1]
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7007c90f
  12. 08 11月, 2012 2 次提交
  13. 18 9月, 2012 1 次提交
    • E
      userns: Pass a userns parameter into posix_acl_to_xattr and posix_acl_from_xattr · 5f3a4a28
      Eric W. Biederman 提交于
       - Pass the user namespace the uid and gid values in the xattr are stored
         in into posix_acl_from_xattr.
      
       - Pass the user namespace kuid and kgid values should be converted into
         when storing uid and gid values in an xattr in posix_acl_to_xattr.
      
      - Modify all callers of posix_acl_from_xattr and posix_acl_to_xattr to
        pass in &init_user_ns.
      
      In the short term this change is not strictly needed but it makes the
      code clearer.  In the longer term this change is necessary to be able to
      mount filesystems outside of the initial user namespace that natively
      store posix acls in the linux xattr format.
      
      Cc: Theodore Tso <tytso@mit.edu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      5f3a4a28
  14. 11 9月, 2012 1 次提交
  15. 31 7月, 2012 1 次提交
  16. 23 7月, 2012 1 次提交
  17. 14 7月, 2012 1 次提交
  18. 11 7月, 2012 1 次提交
    • J
      nfsd: allow owner_override only for regular files · d91d0b56
      J. Bruce Fields 提交于
      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: NJ. Bruce Fields <bfields@redhat.com>
      d91d0b56
  19. 26 4月, 2012 1 次提交
  20. 12 4月, 2012 1 次提交
    • J
      nfsd: don't fail unchecked creates of non-special files · 9dc4e6c4
      J. Bruce Fields 提交于
      Allow a v3 unchecked open of a non-regular file succeed as if it were a
      lookup; typically a client in such a case will want to fall back on a
      local open, so succeeding and giving it the filehandle is more useful
      than failing with nfserr_exist, which makes it appear that nothing at
      all exists by that name.
      
      Similarly for v4, on an open-create, return the same errors we would on
      an attempt to open a non-regular file, instead of returning
      nfserr_exist.
      
      This fixes a problem found doing a v4 open of a symlink with
      O_RDONLY|O_CREAT, which resulted in the current client returning EEXIST.
      
      Thanks also to Trond for analysis.
      
      Cc: stable@kernel.org
      Reported-by: NOrion Poplawski <orion@cora.nwra.com>
      Tested-by: NOrion Poplawski <orion@cora.nwra.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9dc4e6c4
  21. 21 3月, 2012 1 次提交
  22. 19 3月, 2012 2 次提交
  23. 06 1月, 2012 1 次提交
    • C
      NFSD: Change name of extended attribute containing junction · 9b4146e8
      Chuck Lever 提交于
      As of fedfs-utils-0.8.0, user space stores all NFS junction
      information in a single extended attribute: "trusted.junction.nfs".
      
      Both FedFS and NFS basic junctions are stored in this one attribute,
      and the intention is that all future forms of NFS junction metadata
      will be stored in this attribute.  Other protocols may use a different
      extended attribute.
      
      Thus NFSD needs to look only for that one extended attribute.  The
      "trusted.junction.type" xattr is deprecated.  fedfs-utils-0.8.0 will
      continue to attach a "trusted.junction.type" xattr to junctions, but
      future fedfs-utils releases may no longer do that.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9b4146e8
  24. 04 1月, 2012 2 次提交
  25. 18 10月, 2011 1 次提交
  26. 14 9月, 2011 1 次提交
  27. 28 8月, 2011 1 次提交
    • J
      nfsd4: permit read opens of executable-only files · a043226b
      J. Bruce Fields 提交于
      A client that wants to execute a file must be able to read it.  Read
      opens over nfs are therefore implicitly allowed for executable files
      even when those files are not readable.
      
      NFSv2/v3 get this right by using a passed-in NFSD_MAY_OWNER_OVERRIDE on
      read requests, but NFSv4 has gotten this wrong ever since
      dc730e17 "nfsd4: fix owner-override on
      open", when we realized that the file owner shouldn't override
      permissions on non-reclaim NFSv4 opens.
      
      So we can't use NFSD_MAY_OWNER_OVERRIDE to tell nfsd_permission to allow
      reads of executable files.
      
      So, do the same thing we do whenever we encounter another weird NFS
      permission nit: define yet another NFSD_MAY_* flag.
      
      The industry's future standardization on 128-bit processors will be
      motivated primarily by the need for integers with enough bits for all
      the NFSD_MAY_* flags.
      Reported-by: NLeonardo Borda <leonardoborda@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      a043226b
  28. 27 8月, 2011 2 次提交
  29. 20 6月, 2011 1 次提交
  30. 07 6月, 2011 1 次提交
  31. 30 4月, 2011 2 次提交
  32. 20 4月, 2011 1 次提交
    • S
      Open with O_CREAT flag set fails to open existing files on non writable directories · 1574dff8
      Sachin Prabhu 提交于
      An open on a NFS4 share using the O_CREAT flag on an existing file for
      which we have permissions to open but contained in a directory with no
      write permissions will fail with EACCES.
      
      A tcpdump shows that the client had set the open mode to UNCHECKED which
      indicates that the file should be created if it doesn't exist and
      encountering an existing flag is not an error. Since in this case the
      file exists and can be opened by the user, the NFS server is wrong in
      attempting to check create permissions on the parent directory.
      
      The patch adds a conditional statement to check for create permissions
      only if the file doesn't exist.
      Signed-off-by: NSachin S. Prabhu <sprabhu@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      1574dff8
  33. 11 4月, 2011 1 次提交