1. 30 May, 2014 13 commits
  2. 28 May, 2014 5 commits
  3. 27 May, 2014 2 commits
  4. 23 May, 2014 9 commits
  5. 22 May, 2014 7 commits
  6. 21 May, 2014 4 commits
    • J. Bruce Fields's avatar
      nfsd4: fix delegation cleanup on error · cbf7a75b
      J. Bruce Fields authored
      We're not cleaning up everything we need to on error.  In particular,
      we're not removing our lease.  Among other problems this can cause the
      struct nfs4_file used as fl_owner to be referenced after it has been
      destroyed.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      cbf7a75b
    • Kinglong Mee's avatar
      NFSD: Don't clear SUID/SGID after root writing data · 368fe39b
      Kinglong Mee authored
      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: default avatarKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      368fe39b
    • J. Bruce Fields's avatar
      nfsd4: warn on finding lockowner without stateid's · 27b11428
      J. Bruce Fields authored
      The current code assumes a one-to-one lockowner<->lock stateid
      correspondance.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      27b11428
    • J. Bruce Fields's avatar
      nfsd4: remove lockowner when removing lock stateid · a1b8ff4c
      J. Bruce Fields authored
      The nfsv4 state code has always assumed a one-to-one correspondance
      between lock stateid's and lockowners even if it appears not to in some
      places.
      
      We may actually change that, but for now when FREE_STATEID releases a
      lock stateid it also needs to release the parent lockowner.
      
      Symptoms were a subsequent LOCK crashing in find_lockowner_str when it
      calls same_lockowner_ino on a lockowner that unexpectedly has an empty
      so_stateids list.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      a1b8ff4c