[SRU] libnss-ldap for edgy-proposed: Problem with LDAPS

Bug #70146 reported by Jean-Michel Dault
18
Affects Status Importance Assigned to Milestone
libnss-ldap (Ubuntu)
Invalid
High
LaMont Jones

Bug Description

I can't connect with SSL using libnss-ldap version 251-5.2.

It seems that strace always keeps connecting to port 389:
stat64("/etc/libnss-ldap.conf", {st_mode=S_IFREG|0644, st_size=307, ...}) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.2.224")}, 16) = -1 EINPROGRESS (Operation now in progress)

My /etc/libnss-ldap.conf gives this:
===
host 192.168.2.224
ssl on
nss_base_passwd ou=People,dc=revolutionlinux,dc=com?one
nss_base_shadow ou=People,dc=revolutionlinux,dc=com?one
nss_base_group ou=Group,dc=revolutionlinux,dc=com?one
tls_checkpeer no
===

If I copy /lib/libnss_ldap-2.3.6.so from a 6.06 LTS, amd make a symlink to /lib/libnss_ldap.so.2, everything works again:

connect(4, {sa_family=AF_INET, sin_port=htons(636), sin_addr=inet_addr("192.168.2.224")}, 16) = -1 EINPROGRESS (Operation now in progress)

Revision history for this message
LaMont Jones (lamont) wrote :

I will assume that you're referring to it hanging inside of glibc...

getent and ldapsearch work; finger and authentication (login, sudo, etc) do not.

This issue is fixed in upstream libnss-ldap 253 with a comment of:
253 Luke Howard <email address hidden>

        * fix crasher if an empty buffer is passed to
          initgroups (glibc NSS only)

Installing 253 fixes the issue here, I'm working on finding and backporting just that patch.

Changed in libnss-ldap:
assignee: nobody → lamont
importance: Undecided → High
status: Unconfirmed → Confirmed
Revision history for this message
LaMont Jones (lamont) wrote :

The following patch backports just the changes for version 253, and fixes the issue at least on my system.

can you confirm that it fixes things for you? I can provide a .deb if you want.

Revision history for this message
LaMont Jones (lamont) wrote :

This bug appears to be triggered by glibc 2.4, and results in users not being able to login (or much else) on machines where users/groups are stored in ldap. As such, this represents a serious regression from dapper.

Revision history for this message
Reinhard Tartler (siretart) wrote :

The patch looks apropriate. Let's test that in -proposed.

Revision history for this message
StefanPotyra (sistpoty) wrote :

Looks pretty sane to me as well. +1.

Revision history for this message
Steve Kowalik (stevenk) wrote :

The patch also looks sane to me. +1

Revision history for this message
Andrew Mitchell (ajmitch) wrote :

+1 from me as well

Revision history for this message
StefanPotyra (sistpoty) wrote :

Please go ahead and upload to edgy-proposed. Thanks.

Revision history for this message
Jean-Michel Dault (jmdault) wrote :

The proposed patch might fix other issues, but it doesn't fix the problem I reported. ;-)

It seems that in versions of nss_ldap >=241, you need to specify the port in the hostname, or use an URI for ldaps to work. The bug is also present in version 253 compiled from source.

If I change my config to: "host 192.168.2.224:636", it works.

I need to find out what changed between 240 and 241... Unfortunately, I can't find version 241 to 243 anywhere, and I'm afraid a diff from 240 and 244 will be quite huge, so it will be hard to fix.

Will report to upstream.

Revision history for this message
Jean-Michel Dault (jmdault) wrote :
Revision history for this message
Tollef Fog Heen (tfheen) wrote :

Accepted into -proposed, please solicit testing as per https://wiki.ubuntu.com/MOTU/SRU

Changed in libnss-ldap:
status: Confirmed → Fix Committed
Revision history for this message
Lionel Porcheron (lionel.porcheron) wrote :

libnss-ldap 251-5.2ubuntu1~proposed in edgy proposed fixed the issue for me.

Revision history for this message
Leitet (lime) wrote :

I am using 251-5.2ubuntu1~proposed, but it doesn't work here.

Works:
When I specify:
 host ldap.host.here:636

Works not:
When I specify:
 host ldap.host here
 port 636
Or:
 uri ldaps://ldap.host.here/

Revision history for this message
Henti Smith (henti) wrote :

This seems to happen in feisty as well.

Same problem with host/uri in config as well, host works, uri does not.

Going to try and roll back to LTS version to test if the hanging can be resolved as well.

currently testing on libnss-ldap version 251-7.5 on feisty

Revision history for this message
Stephan Buys (stephan-buys) wrote :

From an strace that we ran on getent passwd it seemed that the problem might be related to Avahi?

Revision history for this message
Henti Smith (henti) wrote :

Using the edgy libnss_ldap librarty on feisty works as well :)

Can this be fixed in feisty :)

Cheers

Revision history for this message
Henti Smith (henti) wrote :

Using the linbss_ldap-2.4 does allow you to auth on feisty .. but seg faults on pretty much everything after that .. so obviously this is not a desirable fix.

Will look into other options to get this working ..

Revision history for this message
Henti Smith (henti) wrote :

This seemed to have been a faulty install somehow ... reinstall worked as expected without needing any other version of libnnsldap

Revision history for this message
Cian Davis (davisc) wrote :

Is the 253 version in a repo somewhere? I wouldn't mind testing it. Still getting problems similar to bug 51315 with Courier - complaining it can't contact the LDAP server in auth.log.

Revision history for this message
Martin Pitt (pitti) wrote :

There seems to be some confusion and one successful test here. If you guys still care about edgy-proposed, please do a followup upload to edgy-updates which drops the ~proposed1 version suffix. If nobody cares any more, I'll just remove the proposed version.

Revision history for this message
Martin Pitt (pitti) wrote :

Removed package from edgy-proposed due to inactivity.

Changed in libnss-ldap:
status: Fix Committed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.