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.

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

Frank


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