Re: libgssapi causing login failures

On Tue, 2007-05-08 at 09:15 +0200, Harti Brandt wrote:
> 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.
> 

Thanks Harti, that did the trick.  Still another issue on -CURRENT with
sshd and nss_ldap breaking logins but it looks unrelated to libgssapi.
Can you commit this?

tom

> 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
-- 
| tmclaugh at sdf.lonestar.org             tmclaugh at FreeBSD.org |
| FreeBSD                                   http://www.FreeBSD.org |
| BSD#                    http://www.mono-project.com/Mono:FreeBSD |