RE: NFSv4 security negotiation issue

["Frank Filz" <ffilzlnx@mindspring.com>]

> >> On Sep 15, 2015, at 1:41 PM, Frank Filz <ffilzlnx@mindspring.com>
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.

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...

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus