1. 24 Jun, 2016 1 commit
    • Ben Hutchings's avatar
      nfsd: check permissions when setting ACLs · 99965378
      Ben Hutchings authored
      Use set_posix_acl, which includes proper permission checks, instead of
      calling ->set_acl directly.  Without this anyone may be able to grant
      themselves permissions to a file by setting the ACL.
      
      Lock the inode to make the new checks atomic with respect to set_acl.
      (Also, nfsd was the only caller of set_acl not locking the inode, so I
      suspect this may fix other races.)
      
      This also simplifies the code, and ensures our ACLs are checked by
      posix_acl_valid.
      
      The permission checks and the inode locking were lost with commit
      4ac7249e, which changed nfsd to use the set_acl inode operation directly
      instead of going through xattr handlers.
      Reported-by: default avatarDavid Sinquin <david@sinquin.eu>
      [agreunba@redhat.com: use set_posix_acl]
      Fixes: 4ac7249e
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      99965378
  2. 15 Jun, 2016 4 commits
  3. 14 Jun, 2016 1 commit
  4. 13 May, 2016 2 commits
  5. 01 May, 2016 1 commit
  6. 10 Apr, 2016 1 commit
  7. 23 Mar, 2016 1 commit
  8. 22 Mar, 2016 1 commit
  9. 18 Mar, 2016 4 commits
  10. 17 Mar, 2016 1 commit
  11. 16 Mar, 2016 1 commit
    • J. Bruce Fields's avatar
      nfsd: fix deadlock secinfo+readdir compound · 2f6fc056
      J. Bruce Fields authored
      nfsd_lookup_dentry exits with the parent filehandle locked.  fh_put also
      unlocks if necessary (nfsd filehandle locking is probably too lenient),
      so it gets unlocked eventually, but if the following op in the compound
      needs to lock it again, we can deadlock.
      
      A fuzzer ran into this; normal clients don't send a secinfo followed by
      a readdir in the same compound.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      2f6fc056
  12. 04 Mar, 2016 1 commit
  13. 02 Mar, 2016 1 commit
  14. 01 Mar, 2016 4 commits
  15. 27 Jan, 2016 1 commit
  16. 22 Jan, 2016 1 commit
    • Al Viro's avatar
      wrappers for ->i_mutex access · 5955102c
      Al Viro authored
      parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested},
      inode_foo(inode) being mutex_foo(&inode->i_mutex).
      
      Please, use those for access to ->i_mutex; over the coming cycle
      ->i_mutex will become rwsem, with ->lookup() done with it held
      only shared.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      5955102c
  17. 14 Jan, 2016 1 commit
  18. 09 Jan, 2016 1 commit
    • NeilBrown's avatar
      nfsd: don't hold i_mutex over userspace upcalls · bbddca8e
      NeilBrown authored
      We need information about exports when crossing mountpoints during
      lookup or NFSv4 readdir.  If we don't already have that information
      cached, we may have to ask (and wait for) rpc.mountd.
      
      In both cases we currently hold the i_mutex on the parent of the
      directory we're asking rpc.mountd about.  We've seen situations where
      rpc.mountd performs some operation on that directory that tries to take
      the i_mutex again, resulting in deadlock.
      
      With some care, we may be able to avoid that in rpc.mountd.  But it
      seems better just to avoid holding a mutex while waiting on userspace.
      
      It appears that lookup_one_len is pretty much the only operation that
      needs the i_mutex.  So we could just drop the i_mutex elsewhere and do
      something like
      
      	mutex_lock()
      	lookup_one_len()
      	mutex_unlock()
      
      In many cases though the lookup would have been cached and not required
      the i_mutex, so it's more efficient to create a lookup_one_len() variant
      that only takes the i_mutex when necessary.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      bbddca8e
  19. 08 Jan, 2016 1 commit
  20. 07 Jan, 2016 3 commits
  21. 23 Dec, 2015 2 commits
    • Scott Mayhew's avatar
      nfsd: Register callbacks on the inetaddr_chain and inet6addr_chain · 36684996
      Scott Mayhew authored
      Register callbacks on inetaddr_chain and inet6addr_chain to trigger
      cleanup of nfsd transport sockets when an ip address is deleted.
      Signed-off-by: default avatarScott Mayhew <smayhew@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      36684996
    • J. Bruce Fields's avatar
      nfsd: don't base cl_cb_status on stale information · d4f72cb7
      J. Bruce Fields authored
      The rpc client we use to send callbacks may change occasionally.  (In
      the 4.0 case, the client can use setclientid/setclientid_confirm to
      update the callback parameters.  In the 4.1+ case, sessions and
      connections can come and go.)
      
      The update is done from the callback thread by nfsd4_process_cb_update,
      which shuts down the old rpc client and then creates a new one.
      
      The client shutdown kills any ongoing rpc calls.  There won't be any new
      ones till the new one's created and the callback thread moves on.
      
      When an rpc encounters a problem that may suggest callback rpc's
      aren't working any longer, it normally sets NFSD4_CB_DOWN, so the server
      can tell the client something's wrong.
      
      But if the rpc notices CB_UPDATE is set, then the failure may just be a
      normal result of shutting down the callback client.  Or it could just be
      a coincidence, but in any case, it means we're runing with the old
      about-to-be-discarded client, so the failure's not interesting.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      d4f72cb7
  22. 16 Dec, 2015 1 commit
  23. 07 Dec, 2015 2 commits
  24. 24 Nov, 2015 3 commits
    • J. Bruce Fields's avatar
      nfsd4: fix gss-proxy 4.1 mounts for some AD principals · 414ca017
      J. Bruce Fields authored
      The principal name on a gss cred is used to setup the NFSv4.0 callback,
      which has to have a client principal name to authenticate to.
      
      That code wants the name to be in the form servicetype@hostname.
      rpc.svcgssd passes down such names (and passes down no principal name at
      all in the case the principal isn't a service principal).
      
      gss-proxy always passes down the principal name, and passes it down in
      the form servicetype/hostname@REALM.  So we've been munging the name
      gss-proxy passes down into the format the NFSv4.0 callback code expects,
      or throwing away the name if we can't.
      
      Since the introduction of the MACH_CRED enforcement in NFSv4.1, we've
      also been using the principal name to verify that certain operations are
      done as the same principal as was used on the original EXCHANGE_ID call.
      
      For that application, the original name passed down by gss-proxy is also
      useful.
      
      Lack of that name in some cases was causing some kerberized NFSv4.1
      mount failures in an Active Directory environment.
      
      This fix only works in the gss-proxy case.  The fix for legacy
      rpc.svcgssd would be more involved, and rpc.svcgssd already has other
      problems in the AD case.
      Reported-and-tested-by: default avatarJames Ralston <ralston@pobox.com>
      Acked-by: default avatarSimo Sorce <simo@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      414ca017
    • J. Bruce Fields's avatar
      nfsd: fix unlikely NULL deref in mach_creds_match · 920dd9bb
      J. Bruce Fields authored
      We really shouldn't allow a client to be created with cl_mach_cred set
      unless it also has a principal name.
      
      This also allows us to fail such cases immediately on EXCHANGE_ID as
      opposed to waiting and incorrectly returning WRONG_CRED on the following
      CREATE_SESSION.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      920dd9bb
    • J. Bruce Fields's avatar
      nfsd: minor consolidation of mach_cred handling code · 50c7b948
      J. Bruce Fields authored
      Minor cleanup, no change in functionality.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      50c7b948