Details
-
Bug
-
Resolution: Fixed
-
Major
-
Lustre 2.5.3
-
None
-
3
-
9223372036854775807
Description
(This might be related to LU-5730 but as the symptoms are different, I'm opening a new ticket.)
Our users are
Attachments
Issue Links
Activity
I've had the reproducer running over night so far it hasn't triggered the issue, so looking good. I'll leave the reproducer running...
I noticed the patch had been directly attached to the ticket and not to review.whamcloud.com as I would have expected, does this mean it's not yet a good idea to consider applying it to production systems?
I've applied the proposed patch on the MDS and I'm now running the tests.... I guess we'll see tomorrow, though I'll keep running those tests for a t least a day continuously...
This patch will keep FS capability for intent getattr, this is because NFSD will raise FS capability to allow exportfs_decode_fh() to reconnect dentry into dcache, if MDS dropped this capability, reconnect path may fail with -EACCES.
As the NFS export (on a RHEL6 machine) currently doesn't contain either "no_subtree_check" or "subtree_check" and by my reading of the documentation, it seems no_subtree_check is in force, yes. (also confirmed by running exportfs -v.)
I can try (at least on our test system) to re-export with explicit subtree_check and re-test.
Cheers,
Frederik
Is "no_subtree_check" set for the NFS export? It looks like if this feature is set (it's set by default), nfsd_set_fh_dentry() won't set fsuid correctly, but raise capability to allow reconnect_path(), but MDS cleared all FS privileges for lookup (see old_init_ucred()).
yes, it's fsuid that's used in permission check, and it looks like it's mistakenly set somewhere. I'm still checking related code, will update you later.
Yes, 37058 is the owner of top_hT52pM and is the user id that I'm running the tests as:
[bnh65367@ws104 frederik-test]$ ls -lnd top_hT52pM drwx--S---+ 8597 37058 111733 266240 May 11 12:01 top_hT52pM [bnh65367@ws104 frederik-test]$ id uid=37058(bnh65367) gid=37058(bnh65367) groups=37058(bnh65367),500(dcs),37900(dls_staff),37907(dls_sysadmin),37910(dls-softinst),37911(dls-i15),109216(nt11000_2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [bnh65367@ws104 frederik-test]$
uid "1200328" is a random user where I don't recognise the name. Re-running the tests again shows the same mismatch but a different fsuid.
NFS root_squash is enabled, root user (uid=0) is mapped to nfsnobody (uid=65534).
Could you confirm which way round it is, is fsuid the user (apparently) trying to access the file system or is it the apparent owner of the file?
LustreError: 2723:0:(mdd_permission.c:310:__mdd_permission_internal()) permission denied, mode 45c0, fsuid 1200328, uid 37058
shows uid doesn't match, which is the cause permission is denied.
Could you help verify '37058' is owner of "top_hT52pM"? and which should be current test user too. Besides, could you find the user with uid "1200328"?
BTW, what's the status of NFS root_squash? and if it's enabled, what's the uid for root_squash?
FWIW, I've been running our reproducer for nearly 24h after applying the patch. So far we have not seen the permission denied issue at all, so it looks good AFAICT.