From owner-freebsd-fs@freebsd.org Fri Feb 8 23:17:42 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 8B0D414CE0B4 for ; Fri, 8 Feb 2019 23:17:42 +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 1C60271D58 for ; Fri, 8 Feb 2019 23:17:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C987B14CE0B3; Fri, 8 Feb 2019 23:17:41 +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 B7E3914CE0B2 for ; Fri, 8 Feb 2019 23:17:41 +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 4BE5171D54 for ; Fri, 8 Feb 2019 23:17:41 +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 9AC061CBD9 for ; Fri, 8 Feb 2019 23:17:40 +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 x18NHel0006968 for ; Fri, 8 Feb 2019 23:17:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x18NHe3H006967 for fs@FreeBSD.org; Fri, 8 Feb 2019 23:17:40 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: Fri, 08 Feb 2019 23:17:40 +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: rmacklem@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: 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: Fri, 08 Feb 2019 23:17:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235582 --- Comment #5 from Rick Macklem --- Well, if I understood the comments, that would suggest client->cl_cname is NULL. That is weird. I'm not a Kerberos guy, but this says that the server was able to handle the GSSAPI initialization token (basically a Kerberos session ticket + some GSSAPI gobbly gook), but the GSSAPI library doesn't return a principal name for the gss_accept_sec_context() even though it returns GSS_S_COMPLETE. What does this mean in Kerberos land? I have no idea. I can see two ways to handle it. 1 - Consider it a failed authentication. OR 2 - Map it to "nobody". Basically that principal name in client->cl_cname is looked up in the password database and, if it is not found, then the credentials of "nobody" are used instead of the credentials for the user in the password database. --> Since no entry in the password database gets "nobody", it seems that "no principal name" might get the same treatment? I think I'll generate a patch for #2 above and attach it to this PR#, although I have no way to test it. --=20 You are receiving this mail because: You are the assignee for the bug.=