Date: Tue, 08 May 2007 21:06:49 -0400 From: Tom McLaughlin <tmclaugh@sdf.lonestar.org> To: Harti Brandt <harti@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: libgssapi causing login failures Message-ID: <1178672809.1850.6.camel@localhost> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1178672809.1850.6.camel>