On Sep 15, 2015, at 4:28 PM, Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> wrote: >>>> On Sep 15, 2015, at 1:41 PM, Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> > wrote: >>>> >>>>>> There are two shares on the server. >>>>>> >>>>>> The share being mounted is /export/CTHON. It is a sys-only share. >>>>>> No >>>>> "sec=" >>>>>> option is used on the mount command. The expected outcome is that >>>>>> the mount will succeed and use sec=sys. >>>>>> >>>>>> The share that is not being mounted here is /export/KRB5. >>>>>> It is shared with at least krb5i, which means the set of flavors >>>>>> the >>>>> server >>>>>> accepts for the pseudofs includes both krb5i and sys. >>>>>> >>>>>> The client has already negotiated krb5i to access the pseudofs. I >>>>>> see a PUTROOTFH using krb5i and it is successful. The negotiation >>>>>> is not in the >>>>> trace >>>>>> I have. >>>>>> >>>>>> I see a number of GETATTRs then a LOOKUP /export, all with krb5i, >>>>>> all successful. >>>>>> >>>>>> Using krb5i, LOOKUP /CTHON, which fails with WRONGSEC. >>>>>> >>>>>> Client recovers with SECINFO on /CTHON using krb5i. The server >>>>>> responds with a list containing just AUTH_UNIX. >>>>>> >>>>>> Client tries the LOOKUP /CTHON again, now with sys. It works. >>>>>> >>>>>> Similar GETATTR activity using sys as the client mounts this share. >>>>>> >>>>>> Then one last GETATTR, this time using krb5i. The FH is the >>>>>> /export/CTHON directory. This fails with WRONGSEC. >>>>>> >>>>>> The attr mask here is Supported Attrs, FH_Expire_type, >>>>>> Link_Support, Symlink_Support, ACLSupport. This is from >>>>>> nfs4_server_capabilities(), >>>>> which >>>>>> is invoked only in nfs4_proc_get_rootfh() and nfs4_proc_get_root(). >>>>>> >>>>>> The next operation OTW is a RENEW that happens a minute later. >>>>> >>>>> From that sequence, I'm pretty sure we want to fix this in the >>>>> client not the server. >>>>> >>>>> Hmm, did fsid change? >>>> >>>> I'm not sure how to tell. The working LOOKUP operations on >>>> parent/CTHON always return the same FSID. >>> >>> I should have been more clear... Is the fsid for /export different >>> from the fsid for /export/CTHON? If it changes that should produce a new >> superblock. >> >> The PUTROOTFH, GETATTR reply returns an FSID of >> >> fsid4.major = 13172185619750249631 >> fsid4.minor = 0 >> >> The LOOKUP reply for /export returns an FSID of >> >> fsid4.major = 5354380871752655416 >> fsid4.minor = 0 >> >> The LOOKUP reply for /export/CTHON returns an FSID of >> >> fsid4.major = 5354380871752655416 >> fsid4.minor = 0 >> >> But I thought the security policy boundaries on the server did not have to >> correspond with FSID boundaries. > > I think that's a reasonable expectation, though of course there's no > guarantee filehandle guessing couldn't be used to access files in a > different portion of the filesystem. > >>> Does the mount work if sec=sys is specified? >>>> >>>> Yes. >>> >>> And with different mount options, a different superblock should >>> definitely be created. >>> >>> I wonder if there is some way we can push up the security negotiation >>> to help identify a new superblock is necessary, equivalent to having a >>> different mount option? >> >> The question, to me, is whether the client should use the correct security >> flavor for the share right off the bat (because the server has told it to > use sys >> already), or whether it should try to recover from the second WRONGSEC >> instead of failing. > > I think the problem you are having is that the client is trying to re-use > the superblock because FSID and mount options are the same. The problem is > since the security policy is different, a second superblock is required in > this case. When security flavor is specified on mount, that forces a > different superblock because of the difference in mount options. As far as I can see, there are already two super blocks in play. The first is for the pseudofs, which is using krb5i, and one is for the real share, and that is using sys. If nfs4_proc_get_root() used the super block for the real share, the right OTW behavior would occur. > I think it should use the correct flavor, but maybe recovery from the > WRONGSEC is a path to creating a different superblock in this case? > > Hmm, I think my original security negotiation testing might have been before > we added superblock sharing (back in 2006, and really mostly on RHEL 5 as my > testing was primarily in service of backporting security negotiation to RHEL > 5), so I might not have run into this issue even if I had a test that would > trip over it now... -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
