Re: problem with nss_ldap

On 10 Mar 2009, at 11:41, Kostik Belousov wrote:

> 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.

Perhaps I should have put GSS-API extensions in a different library  
from the mechanism implementation. This is actually quite possible  
since all the krb5 extensions are wrappers on a more generic GSS-API  
extension api. Its probably too hard to do that now.