From owner-freebsd-current@FreeBSD.ORG Wed May 9 01:06:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD9C416A402 for ; Wed, 9 May 2007 01:06:55 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from straycat.dhs.org (c-24-63-86-11.hsd1.ma.comcast.net [24.63.86.11]) by mx1.freebsd.org (Postfix) with ESMTP id C7D3B13C46E for ; Wed, 9 May 2007 01:06:54 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from [192.168.1.127] (bofh.straycat.dhs.org [192.168.1.127]) by straycat.dhs.org (8.13.8/8.13.8) with ESMTP id l4916ohD019790; Tue, 8 May 2007 21:06:51 -0400 (EDT) From: Tom McLaughlin To: Harti Brandt In-Reply-To: <20070508091213.A68097@knop-beagle.kn.op.dlr.de> References: <1178587515.1881.50.camel@localhost> <20070508091213.A68097@knop-beagle.kn.op.dlr.de> Content-Type: text/plain Date: Tue, 08 May 2007 21:06:49 -0400 Message-Id: <1178672809.1850.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: libgssapi causing login failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2007 01:06:56 -0000 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@ > 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 > @@ -40,7 +40,7 @@ > 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, > @@ -51,6 +51,7 @@ > 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; > @@ -62,6 +63,11 @@ > > *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 |