Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 7月, 2016 1 次提交
  3. 25 6月, 2016 1 次提交
    • B
      nfsd: check permissions when setting ACLs · 99965378
      由 Ben Hutchings 提交于 
      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: NDavid 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: NJ. Bruce Fields <bfields@redhat.com>
      99965378
  5. 16 6月, 2016 3 次提交
  7. 15 6月, 2016 1 次提交
  9. 14 6月, 2016 1 次提交
  11. 14 5月, 2016 2 次提交
  13. 02 5月, 2016 1 次提交
  15. 11 4月, 2016 1 次提交
  17. 24 3月, 2016 1 次提交
  19. 23 3月, 2016 1 次提交
  21. 18 3月, 2016 5 次提交
  23. 16 3月, 2016 1 次提交
    • J
      nfsd: fix deadlock secinfo+readdir compound · 2f6fc056
      由 J. Bruce Fields 提交于 
      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: NJ. Bruce Fields <bfields@redhat.com>
      2f6fc056
  25. 05 3月, 2016 1 次提交
  27. 03 3月, 2016 1 次提交
  29. 02 3月, 2016 4 次提交
  31. 27 1月, 2016 1 次提交
  33. 23 1月, 2016 1 次提交
    • A
      wrappers for ->i_mutex access · 5955102c
      由 Al Viro 提交于 
      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: NAl Viro <viro@zeniv.linux.org.uk>
      5955102c
  35. 15 1月, 2016 1 次提交
  37. 09 1月, 2016 2 次提交
    • N
      nfsd: don't hold i_mutex over userspace upcalls · bbddca8e
      由 NeilBrown 提交于 
      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: NNeilBrown <neilb@suse.de>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bbddca8e
    • J
      nfsd: give up on CB_LAYOUTRECALLs after two lease periods · 6b9b2107
      由 Jeff Layton 提交于 
      Have the CB_LAYOUTRECALL code treat NFS4_OK and NFS4ERR_DELAY returns
equivalently. Change the code to periodically resend CB_LAYOUTRECALLS
until the ls_layouts list is empty or the client returns a different
error code.

If we go for two lease periods without the list being emptied or the
client sending a hard error, then we give up and clean out the list
anyway.
Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
Tested-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      6b9b2107
  39. 07 1月, 2016 3 次提交
  41. 23 12月, 2015 2 次提交
    • S
      nfsd: Register callbacks on the inetaddr_chain and inet6addr_chain · 36684996
      由 Scott Mayhew 提交于 
      Register callbacks on inetaddr_chain and inet6addr_chain to trigger
cleanup of nfsd transport sockets when an ip address is deleted.
Signed-off-by: NScott Mayhew <smayhew@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      36684996
    • J
      nfsd: don't base cl_cb_status on stale information · d4f72cb7
      由 J. Bruce Fields 提交于 
      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: NJ. Bruce Fields <bfields@redhat.com>
      d4f72cb7
  43. 17 12月, 2015 1 次提交
  45. 08 12月, 2015 2 次提交
  47. 25 11月, 2015 2 次提交
    • J
      nfsd4: fix gss-proxy 4.1 mounts for some AD principals · 414ca017
      由 J. Bruce Fields 提交于 
      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: NJames Ralston <ralston@pobox.com>
Acked-by: NSimo Sorce <simo@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      414ca017
    • J
      nfsd: fix unlikely NULL deref in mach_creds_match · 920dd9bb
      由 J. Bruce Fields 提交于 
      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: NJ. Bruce Fields <bfields@redhat.com>
      920dd9bb