Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Feb 2019 21:56:19 +0000
From:      bugzilla-noreply@freebsd.org
To:        fs@FreeBSD.org
Subject:   [Bug 235582] rpc_svc_gss / nfsd kernel panic
Message-ID:  <bug-235582-3630-vqA3HCgmL4@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-235582-3630@https.bugs.freebsd.org/bugzilla/>
References:  <bug-235582-3630@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235582

--- Comment #14 from Rick Macklem <rmacklem@FreeBSD.org> ---
Well, since that is the output of gss_export_name(), I suspect that
won't be found in the password database and will map to nobody.
Note that the fact that it ends in "@AD.LIU.SE" suggests that the
gss_export_name() isn't doing what it needs to do.

Normally the output of gss_export_name() should be:
For a user principal, just the user, such as "tesje148".
For a host principal, <name>@<host.domain>, such as "nfs@filur00.it.liu.se".
Unless there is an additional step in the GSSAPI to get to the "user" or
"user@domain" name that I have forgotten. (I am not the author of this code,
but I did write a RPCSEC_GSS implementation for the early NFSv4 code I did
long ago.)
Maybe gss_pname_to_unix_cred() does some additional conversion?
(If you add a couple of printf()s in gss_pname_to_unix_cred(), you should
 be able to tell if the cname is translating to a unix cred ok.)

You also might consider testing with my second patch and not the first one
that changes client->cl_cname to a local cname. (I may have screwed the pat=
ch
up, since I can't test them.)

I don't think this is related to the crash.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235582-3630-vqA3HCgmL4>