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