Date: Fri, 08 Feb 2019 23:17:40 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 235582] rpc_svc_gss / nfsd kernel panic Message-ID: <bug-235582-3630-VEXcCH3eQT@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 #5 from Rick Macklem <rmacklem@FreeBSD.org> --- 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235582-3630-VEXcCH3eQT>