From owner-freebsd-fs@freebsd.org Mon Feb 11 15:50:52 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8EA714DA8D4 for ; Mon, 11 Feb 2019 15:50:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4F3733FE for ; Mon, 11 Feb 2019 15:50:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 19FAF14DA8D1; Mon, 11 Feb 2019 15:50:52 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD06E14DA8D0 for ; Mon, 11 Feb 2019 15:50:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64478733F7 for ; Mon, 11 Feb 2019 15:50:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A920A20487 for ; Mon, 11 Feb 2019 15:50:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x1BFoo7A024219 for ; Mon, 11 Feb 2019 15:50:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x1BFoo2v024218 for fs@FreeBSD.org; Mon, 11 Feb 2019 15:50:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 235582] rpc_svc_gss / nfsd kernel panic Date: Mon, 11 Feb 2019 15:50:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bjk@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 15:50:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235582 Benjamin Kaduk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjk@FreeBSD.org --- Comment #17 from Benjamin Kaduk --- 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.=