[Bug 235582] rpc_svc_gss / nfsd kernel panic

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235582

Benjamin Kaduk <bjk at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bjk at FreeBSD.org

--- Comment #17 from Benjamin Kaduk <bjk at FreeBSD.org> ---
As some background (not necessarily helpful, unfortunately) on GSSAPI names,
they are actually fairly complicated objects.

To start with, there are two broad types of name object, an "internal name"
that is something of a generic name string and name type (e.g.,
"host at test.example.com" and GSS_NT_HOSTBASED_SERVICE), and a "mechanism name"
(MN) that contains similar information content but has been restricted to a
single GSSAPI mechanism (e.g., for the krb5 mechanism, you'd get
"host/test.example.com at REALM" for the above example).  So the actual runtime
object is going to have some OIDs associated with it, whether for name type or
mechanism type and perhaps other things.

The original worldview w.r.t. GSSAPI names was that an MN could be converted to
an "export token" that would be treated as an opaque binary string and used for
equality comparison in ACLs, and that there would be a separate "display name"
version that would be used in logging but not for authentication decisions. 
(You can imagine how well that turned out.)  So now we have more advanced
functions like gss_localname() that map a MN to a local username.

I did not look particularly closely at the debugger dump of the cl_name that
had the "expected name" at the end of the buffer; it did look like there were
probably some OIDs and maybe other data in front.  Presumably one could pull
the relevant struct definition from the heimdal internal headers.

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