Date: Mon, 11 Feb 2019 15:50:50 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 235582] rpc_svc_gss / nfsd kernel panic Message-ID: <bug-235582-3630-CTYnFUURZo@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 Benjamin Kaduk <bjk@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjk@FreeBSD.org --- Comment #17 from Benjamin Kaduk <bjk@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@test.example.com" and GSS_NT_HOSTBASED_SERVICE), and a "mechanism nam= e" (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@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 converte= d 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 na= me" version that would be used in logging but not for authentication decisions.= =20 (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 we= re probably some OIDs and maybe other data in front. Presumably one could pull the relevant struct definition from the heimdal internal headers. --=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-CTYnFUURZo>