Re: libgssapi causing login failures

On Mon, 7 May 2007, Tom McLaughlin wrote:

TM>Hi all,
TM>
TM>Since it's ports freeze time I decided to play elsewhere.  I'm putting
TM>up a -CURRENT box here at home synced as of this morning and trying to
TM>get cyrus-sasl2's GSSAPI stuff working with openldap-sasl-client and
TM>nss_ldap and GSSAPI working for authentication with sshd.  It all
TM>already works fine on the -STABLE box here.  After installing
TM>cyrus-sasl2 and openldap-sasl-client I would get a core dump when trying
TM>to bind to the ldap directory using SASL/GSSAPI for authentication.
TM>(Crash info is below.)  I found that about a year and a half ago dfr_at_
TM>made changes to our libgssapi.  For the heck of it I relinked sasl's
TM>libgssapiv2.so.2 from libgssapi.so.8 to libgssapi_krb5.so.8 and I could
TM>bind to the directory using SASL/GSSAPI for authentication.  nss_ldap
TM>started working too.  I have a pretty good feeling what I did isn't the
TM>right fix though.
TM>
TM>Now I want to use GSSAPI to login via ssh.  I'm using the same config as
TM>I do on my -STABLE box but again I can't login and I see the following
TM>in /var/log/messages each time I attempt to connect:
TM>
TM>May  7 14:33:34 releng-7 kernel: pid 84442 (sshd), uid 0: exited on signal 11
TM>
TM>
TM>Is there something I'm missing setup wise on -CURRENT that's different
TM>from -STABLE wrt libgssapi?  Do we need to start checking and fixing
TM>ports on -CURRENT which use libgssapi?  Any help would be greatly
TM>appreciated.  Thanks.

I had the same problem a year ago. The problem is nss_ldap calling one of 
the functions in libgssapi with a NULL argument which should cause the 
function to use the first (or default) entry from /etc/gss/mech, but 
doesn't. I came up with the following patch which makes things work.

Index: gss_init_sec_context.c
===================================================================
RCS file: /local/cvs/freebsd/src/lib/libgssapi/gss_init_sec_context.c,v
retrieving revision 1.1
diff -u -r1.1 gss_init_sec_context.c
--- gss_init_sec_context.c	29 Dec 2005 14:40:20 -0000	1.1
+++ gss_init_sec_context.c	1 Sep 2006 11:42:39 -0000
_at__at_ -40,7 +40,7 _at__at_
     const gss_cred_id_t initiator_cred_handle,
     gss_ctx_id_t * context_handle,
     const gss_name_t target_name,
-    const gss_OID mech_type,
+    const gss_OID imech_type,
     OM_uint32 req_flags,
     OM_uint32 time_req,
     const gss_channel_bindings_t input_chan_bindings,
_at__at_ -51,6 +51,7 _at__at_
     OM_uint32 * time_rec)
 {
 	OM_uint32 major_status;
+	gss_OID mech_type;
 	struct _gss_mech_switch *m;
 	struct _gss_name *name = (struct _gss_name *) target_name;
 	struct _gss_mechanism_name *mn;
_at__at_ -62,6 +63,11 _at__at_
 
 	*minor_status = 0;
 
+	if ((mech_type = imech_type) == GSS_C_NO_OID) {
+		_gss_load_mech();
+		mech_type = &SLIST_FIRST(&_gss_mechs)->gm_mech_oid;
+	}
+
 	/*
 	 * If we haven't allocated a context yet, do so now and lookup
 	 * the mechanism switch table. If we have one already, make

harti