From owner-freebsd-current@FreeBSD.ORG Tue May 8 07:15:07 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 F255116A401 for ; Tue, 8 May 2007 07:15:07 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8FFC613C455 for ; Tue, 8 May 2007 07:15:07 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 09:15:05 +0200 Date: Tue, 8 May 2007 09:15:03 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Tom McLaughlin In-Reply-To: <1178587515.1881.50.camel@localhost> Message-ID: <20070508091213.A68097@knop-beagle.kn.op.dlr.de> References: <1178587515.1881.50.camel@localhost> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 May 2007 07:15:05.0626 (UTC) FILETIME=[9A50A7A0:01C79140] 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 Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2007 07:15:08 -0000 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. 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