1. 10 7月, 2014 1 次提交
  2. 09 7月, 2014 3 次提交
  3. 23 6月, 2014 3 次提交
  4. 31 5月, 2014 3 次提交
  5. 23 5月, 2014 1 次提交
    • N
      nfsd: Only set PF_LESS_THROTTLE when really needed. · 8658452e
      NeilBrown 提交于
      PF_LESS_THROTTLE has a very specific use case: to avoid deadlocks
      and live-locks while writing to the page cache in a loop-back
      NFS mount situation.
      
      It therefore makes sense to *only* set PF_LESS_THROTTLE in this
      situation.
      We now know when a request came from the local-host so it could be a
      loop-back mount.  We already know when we are handling write requests,
      and when we are doing anything else.
      
      So combine those two to allow nfsd to still be throttled (like any
      other process) in every situation except when it is known to be
      problematic.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      8658452e
  6. 22 5月, 2014 1 次提交
    • K
      NFSD: Don't clear SUID/SGID after root writing data · 368fe39b
      Kinglong Mee 提交于
      We're clearing the SUID/SGID bits on write by hand in nfsd_vfs_write,
      even though the subsequent vfs_writev() call will end up doing this for
      us (through file system write methods eventually calling
      file_remove_suid(), e.g., from __generic_file_aio_write).
      
      So, remove the redundant nfsd code.
      
      The only change in behavior is when the write is by root, in which case
      we previously cleared SUID/SGID, but will now leave it alone.  The new
      behavior is the behavior of every filesystem we've checked.
      
      It seems better to be consistent with local filesystem behavior.  And
      the security advantage seems limited as root could always restore these
      bits by hand if it wanted.
      
      SUID/SGID is not cleared after writing data with (root, local ext4),
         File: ‘test’
         Size: 0               Blocks: 0          IO Block: 4096   regular
      empty file
      Device: 803h/2051d      Inode: 1200137     Links: 1
      Access: (4777/-rwsrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
      Context: unconfined_u:object_r:admin_home_t:s0
      Access: 2014-04-18 21:36:31.016029014 +0800
      Modify: 2014-04-18 21:36:31.016029014 +0800
      Change: 2014-04-18 21:36:31.026030285 +0800
        Birth: -
         File: ‘test’
         Size: 5               Blocks: 8          IO Block: 4096   regular file
      Device: 803h/2051d      Inode: 1200137     Links: 1
      Access: (4777/-rwsrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
      Context: unconfined_u:object_r:admin_home_t:s0
      Access: 2014-04-18 21:36:31.016029014 +0800
      Modify: 2014-04-18 21:36:31.040032065 +0800
      Change: 2014-04-18 21:36:31.040032065 +0800
        Birth: -
      
      With no_root_squash, (root, remote ext4), SUID/SGID are cleared,
         File: ‘test’
         Size: 0               Blocks: 0          IO Block: 262144 regular
      empty file
      Device: 24h/36d Inode: 786439      Links: 1
      Access: (4777/-rwsrwxrwx)  Uid: ( 1000/    test)   Gid: ( 1000/    test)
      Context: system_u:object_r:nfs_t:s0
      Access: 2014-04-18 21:45:32.155805097 +0800
      Modify: 2014-04-18 21:45:32.155805097 +0800
      Change: 2014-04-18 21:45:32.168806749 +0800
        Birth: -
         File: ‘test’
         Size: 5               Blocks: 8          IO Block: 262144 regular file
      Device: 24h/36d Inode: 786439      Links: 1
      Access: (0777/-rwxrwxrwx)  Uid: ( 1000/    test)   Gid: ( 1000/    test)
      Context: system_u:object_r:nfs_t:s0
      Access: 2014-04-18 21:45:32.155805097 +0800
      Modify: 2014-04-18 21:45:32.184808783 +0800
      Change: 2014-04-18 21:45:32.184808783 +0800
        Birth: -
      Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      368fe39b
  7. 01 4月, 2014 1 次提交
  8. 29 3月, 2014 1 次提交
  9. 28 3月, 2014 1 次提交
  10. 19 2月, 2014 1 次提交
  11. 28 1月, 2014 1 次提交
    • J
      nfsd4: fix delegation-unlink/rename race · 4335723e
      J. Bruce Fields 提交于
      If a file is unlinked or renamed between the time when we do the local
      open and the time when we get the delegation, then we will return to the
      client indicating that it holds a delegation even though the file no
      longer exists under the name it was open under.
      
      But a client performing an open-by-name, when it is returned a
      delegation, must be able to assume that the file is still linked at the
      name it was opened under.
      
      So, hold the parent i_mutex for longer to prevent concurrent renames or
      unlinks.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      4335723e
  12. 26 1月, 2014 1 次提交
  13. 08 1月, 2014 1 次提交
    • J
      nfsd4: break only delegations when appropriate · 208d0acc
      J. Bruce Fields 提交于
      As a temporary fix, nfsd was breaking all leases on unlink, link,
      rename, and setattr.
      
      Now that we can distinguish between leases and delegations, we can be
      nicer and break only the delegations, and not bother lease-holders with
      operations they don't care about.
      
      And we get to delete some code while we're at it.
      
      Note that in the presence of delegations the vfs calls here all return
      -EWOULDBLOCK instead of blocking, so nfsd threads will not get stuck
      waiting for delegation returns.
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      208d0acc
  14. 13 12月, 2013 1 次提交
    • S
      nfsd: revoking of suid/sgid bits after chown() in a consistent way · c4fa6d7c
      Stanislav Kholmanskikh 提交于
      There is an inconsistency in the handling of SUID/SGID file
      bits after chown() between NFS and other local file systems.
      
      Local file systems (for example, ext3, ext4, xfs, btrfs) revoke
      SUID/SGID bits after chown() on a regular file even if
      the owner/group of the file has not been changed:
      
      ~# touch file; chmod ug+s file; chmod u+x file
      ~# ls -l file
      -rwsr-Sr-- 1 root root 0 Dec  6 04:49 file
      ~# chown root file; ls -l file
      -rwxr-Sr-- 1 root root 0 Dec  6 04:49 file
      
      but NFS doesn't do that:
      
      ~# touch file; chmod ug+s file; chmod u+x file
      ~# ls -l file
      -rwsr-Sr-- 1 root root 0 Dec  6 04:49 file
      ~# chown root file; ls -l file
      -rwsr-Sr-- 1 root root 0 Dec  6 04:49 file
      
      NFS does that only if the owner/group has been changed:
      
      ~# touch file; chmod ug+s file; chmod u+x file
      ~# ls -l file
      -rwsr-Sr-- 1 root root 0 Dec  6 05:02 file
      ~# chown bin file; ls -l file
      -rwxr-Sr-- 1 bin root 0 Dec  6 05:02 file
      
      See: http://pubs.opengroup.org/onlinepubs/9699919799/functions/chown.html
      
       "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 has appropriate privileges, it is
       implementation-defined whether the set-user-ID and set-group-ID
       bits are altered."
      
      So both variants are acceptable by POSIX.
      
      This patch makes NFS to behave like local file systems.
      Signed-off-by: NStanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c4fa6d7c
  15. 19 11月, 2013 2 次提交
  16. 09 11月, 2013 4 次提交
  17. 25 10月, 2013 1 次提交
  18. 03 10月, 2013 1 次提交
  19. 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
  20. 29 6月, 2013 2 次提交
  21. 15 5月, 2013 1 次提交
  22. 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
  23. 23 3月, 2013 1 次提交
  24. 23 2月, 2013 1 次提交
  25. 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
  26. 22 12月, 2012 1 次提交
  27. 18 12月, 2012 2 次提交
  28. 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