problem with nss_ldap

Tue Mar 10 04:41:40 PDT 2009

On Tue, Mar 10, 2009 at 10:38:51AM +0000, Doug Rabson wrote:
> 
> On 6 Mar 2009, at 22:24, Kostik Belousov wrote:
> 
> >On Fri, Mar 06, 2009 at 05:00:49PM -0500, tmclaugh at sdf.lonestar.org  
> >wrote:
> >>>On Fri, Mar 06, 2009 at 09:39:31PM +0100, Hartmut Brandt wrote:
> >>>>
> >>>>Hi Tom,
> >>>>
> >>>>On Sat, 28 Feb 2009, Tom McLaughlin wrote:
> >>>>
> >>>>TM>Tom McLaughlin wrote:
> >>>>TM>> Harti Brandt wrote:
> >>>>TM>> > On Sun, 18 Jan 2009, Hartmut.Brandt at dlr.de wrote:
> >>>>TM>
> >>>>TM>> > > Both create entries in /var/log/messages like:
> >>>>TM>> > >
> >>>>TM>> > > Jan 18 20:00:02 knopdnsimu13f cron[1495]: GSSAPI Error:
> >>>>Miscellaneous
> >>>>TM>> > > failure (see
> >>>>TM>> > >
> >>>>text)??????????????? 
> >>>>ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> >>>>TM>Z
> >>>>TM>> Z
> >>>>TM>> >  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> >>>>TM>> > > Jan 18 20:00:02 knopdnsimu13f kernel: ZZZZZZZZZZZZZZZZ
> >>>>TM>> > >
> >>>>TM>> > > I've tried to figure out in which of the dozens of layered
> >>>>libraries
> >>>>TM>> > > (gss, sasl, ssl, ......) this error is generated but did  
> >>>>not
> >>>>find
> >>>>TM>> > > anything.
> >>>>TM>> > >
> >>>>TM>> > > This is on amd64, krb5 enabled in pam, gssapi disabled in
> >>>>sshd_config
> >>>>TM>> > > (as I said, this worked before).
> >>>>TM>> > So to answer my own mail: I made a link from the kerberos  
> >>>>ticket
> >>>>file
> >>>>TM>> > which contains the host ticket (and is specified in
> >>>>nss_ldap.conf) to
> >>>>TM>> > /tmp/krb5cc_0. I've no idea why this is suddenly necessary,
> >>>>though.
> >>>>TM>>
> >>>>TM>> There may be an issue with the env method used in nss_ldap to
> >>>>change the
> >>>>TM>> credentials cache.  My mind is fuzzy but I do recall a similar
> >>>>issue but
> >>>>TM>> don't remember the exact cause or case.  nss_ldap has a second
> >>>>configurable
> >>>>TM>> ccname method which when I submitted the original patch I  
> >>>>intended
> >>>>to
> >>>>TM>> switch to once we had a newer heimdal.  Once I get nss_ldap  
> >>>>working
> >>>>on my
> >>>>TM>> box I intend to submit another patch.
> >>>>TM>>
> >>>>TM>> tom
> >>>>TM>
> >>>>TM>Hi Harti (CC maintainer),
> >>>>TM>
> >>>>TM>Can you try the attached patch for nss_ldap?  This should  
> >>>>cause the
> >>>>host
> >>>>TM>ticket to work correctly on -CURRENT.  It's "my box approved".
> >>>>
> >>>>Does not work. I rebuilt my system with today's sources to be sure,
> >>>>removed my patches to the two library makefiles and rebuilt  
> >>>>nss_ldap
> >>>>with
> >>>>your patch. I get:
> >>>>
> >>>># ls -l
> >>>>dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol
> >>>>"GSS_C_NT_HOSTBASED_SERVICE"
> >>>>/libexec/ld-elf.so.1: /usr/lib/libgssapi_krb5.so.10: Undefined  
> >>>>symbol
> >>>>"gss_oid_equal"
> >>>>
> >>>>Basically on everything I enter. Luckily vi still works :-)
> >>>>
> >>>>I saw that the configuration script claims not to find
> >>>>gss_krb5_ccache_name in -lgssapi or -lgssapi_krb5. This is  
> >>>>because the
> >>>>test program for -lgssapi_krb5 links only to gssapi_krb5 but not to
> >>>>gssapi
> >>>>and so gets a lot of errors. I fixed this by adding gssapi, but the
> >>>>final
> >>>>result was the same.
> >>>
> >>>It seems that this is because libgssapi_krb5, libgssapi_spnego
> >>>and several other heimdal shared libraries are not linked against
> >>>libgssapi.
> >>>
> >>>
> >>
> >>As I understand it libgssapi_krb5 and libgssapi_spnego are not  
> >>supposed to
> >>be linked against libgssapi.  They're supposed to be just plugins.
> >
> >These objects reference symbols from libgssapi. The libgssapi or  
> >nss_ldap
> >are dlopened without RTLD_GLOBAL flag, and libgssapi-provided symbols
> >are not available. As I understand, nss module must be not loaded with
> >RTLD_GLOBAL.
> >
> >Our binutils in base are old. Newer ld has a switch --no-allow-shlib- 
> >undefined
> >that fails the link if shared library has undefined references. I find
> >it useful to catch and fix this kind of errors.
> 
> 
> The real problem is that nss_ldap should not link with libgssapi_krb5  
> directly. This library is a plugin for the mechanism-independant  
> libgssapi and can not be used standalone. The nss_ldap module should  
> link to libgssapi and that will handle loading libgssapi_krb5 as  
> necessary.
> 
I think this is a different problem, and it does not invalidates the
requirement for each dso to be linked against all required dso's that
provide symbols referenced by the first one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090310/cf82c3a2/attachment.pgp