Debian GNU/Linux

NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec, and atd

Reported by Matt Kassawara on 2009-09-02
586
This bug affects 109 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Undecided
Unassigned
eglibc (Ubuntu)
Karmic
Undecided
Unassigned
Lucid
Undecided
Unassigned
Maverick
Undecided
Unassigned
Natty
Undecided
Unassigned
Oneiric
Undecided
Unassigned
Precise
Undecided
Unassigned
gnutls26 (Debian)
Confirmed
Unknown
libgcrypt11 (Debian)
Confirmed
Unknown
libgcrypt11 (Ubuntu)
Medium
Unassigned
Karmic
Medium
Unassigned
Lucid
Medium
Canonical Foundations Team
Maverick
Medium
Canonical Foundations Team
Natty
Undecided
Unassigned
Oneiric
Undecided
Unassigned
Precise
Undecided
Unassigned
libnss-ldap (Ubuntu)
Karmic
Undecided
Unassigned
Lucid
Medium
Unassigned
Maverick
Undecided
Unassigned
Natty
Undecided
Unassigned
Oneiric
Undecided
Unassigned
Precise
Undecided
Unassigned
openldap (Debian)
New
Undecided
Unassigned
sudo (Debian)
Confirmed
Unknown
sudo (Kairos Linux)
Confirmed
High
Philipp Kaluza
sudo (Ubuntu)
Karmic
Undecided
Unassigned
Lucid
Medium
Mathias Gug
Maverick
Undecided
Unassigned
Natty
Undecided
Unassigned
Oneiric
Undecided
Unassigned
Precise
Undecided
Unassigned

Bug Description

SRU Request:

[Impact]
As heavily outlined in the amount of comments in this bug the impact is detrimental to both community and enterprise users alike.

[Development Fix]
Howard Chu released a patch in #73 which was later confirmed in #106 & #108 as a resolution.

[Stable Fix]
Patch from #73 can be applied cleanly to Lucid and new distributions.

[Test Case]
On Karmic (alpha 4 plus updates), changing the nsswitch.conf 'passwd' field to anything with 'ldap' as the first item breaks the ability to become root using 'su' and 'sudo' as anyone but root.

Default nsswitch.conf:

passwd: compat
group: compat
shadow: compat

matt@box:~$ sudo uname -a
[sudo] password for matt:
Linux box 2.6.31-9-server #29-Ubuntu SMP Sun Aug 30 18:37:42 UTC 2009 x86_64 GNU/Linux

matt@box:~$ su -
Password:
root@box:~#

Modified nsswitch.conf with 'ldap' before 'compat':

passwd: ldap compat
group: ldap compat
shadow: ldap compat

matt@box:~$ sudo uname -a
sudo: setreuid(ROOT_UID, user_uid): Operation not permitted

matt@box:~$ su -
Password:
setgid: Operation not permitted

Modified nsswitch.conf with 'ldap' after 'compat':

passwd: compat ldap
group: compat ldap
shadow: compat ldap

matt@box:~$ sudo uname -a
[sudo] password for matt:
Linux box 2.6.31-9-server #29-Ubuntu SMP Sun Aug 30 18:37:42 UTC 2009 x86_64 GNU/Linux

matt@box:~$ su -
Password:
root@box:~#

The same arrangements in nsswitch.conf work as expected in Jaunty and earlier releases.

[Regression Potential]
This should be minimal as the code change only addresses the duplicating global_init during thread callbacks.

Lucid Release Note:

== NSS via LDAP+SSL breaks setuid applications like sudo ==

Upgrading systems configured to use ldap over ssl as the first service in the nss stack (in nsswitch.conf) leads to a broken nss resolution for setuid applications after the upgrade to Lucid (for example sudo would stop working). There isn't any simple workaround for now. One option is to switch to libnss-ldapd in place of libnss-ldap before the upgrade. Another one consists in using nscd before the upgrade.

Eric Carvalho (eric-carvalho) wrote :

Bug still present on Karmic alpha 5.

Changed in glibc (Ubuntu):
status: New → Confirmed
Scott Grizzard (sgrizzard) wrote :

Workaround:

It's a bit clunky, but if it is driving you nuts, you can add the user information to the local /etc/passwd file, and the user will be able to use sudo and su.

The catch is that the user_id and the user_name must be the same in both ldap and the local /etc/passwd. It sort of defeats the purpose of ldap, but if you only have one admin user, it works fine.

John Affleck (lists+launchpad) wrote :

Apparently still present in RC. As a clarification, users present in /etc/passwd can still sudo just fine. Users present only via ldap cannot.

My suspicion is that the initial reporter had, as Scott G. suggested, the user present both via ldap and /etc/passwd, with the result that hitting the local file first (via compat) made it work, versus hitting ldap first makes it break.

passwd: files ldap
..does not work for me (with the user present only via ldap).
passwd: files compat ldap
..also does not work:
> sudo ls /tmp
sudo: setreuid(ROOT_UID, user_uid): Operation not permitted

Yuck.

Perhaps sudo/sudo-ldap are more appropriate packages ? It appears to be sudo-ldap 1.7.2-2 related (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545414)

John Affleck (lists+launchpad) wrote :

Eh. Going back to the Jaunty version of sudo didn't appear to help, so maybe it's not the sudo package itself ?

This did work on Jaunty.

Geoffroy (dgeo) wrote :

I do not have this problem...

My nsswitch.conf looks like:
passwd: files ldap
group: files ldap
shadow: files ldap

my user only exists in LDAP, but is mentionned in /etc/group (sudo group)

sudoers shows:
%sudo ALL=(ALL) ALL

then:
$ sudo uname -a
Linux dgeos 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

I did not notice this particular bug before...

I did last upgrade this morning...

Winckler (winckler) wrote :

I'm also affected by this bug, but in my case it only happens with ldaps (LDAP over SSL) connections.

When I switch from ldaps:// to ldap://, everything begin to work fine again.

Maybe this would help to debug. (I have a self-signed cert in the LDAP server)

John Affleck (lists+launchpad) wrote :

I can also make it work by using ldap instead of ldaps. (and am also using a self-signed cert for the ldap server).

Lawren Quigley-Jones (lawrenqj) wrote :

I couldn't test ldap vs. ldaps, but sudo was working before my karmic upgrade and it stopped working after. I could do getent operations which did ldap queries, so it wasn't an ldap problem for me.

I was able to ~solve~ this by installing nscd. Not sure why there would be a nscd requirement.

Here's my nsswitch.conf:
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: files ldap

I'm not sure what else to include for debugging...

Michael (michael-rigoni) wrote :

Had the same problem, installing nscd seems to have solved the issue.

However, I noticed that I had that issue with ldap users, when I was accessing ldap over SSL:

my nsswitch.conf (only usefull lines...):
----------------------------------------
passwd: files ldap [NOTFOUND=return] db
group: files ldap [NOTFOUND=return] db
shadow: files
---------------------------------------

my /etc/ldap.conf :
-----------------------------------------
base ********************
host ********************
ldap_version 3

ssl on
tls_cacertfile /etc/ssl/certs/myCA.crt
tls_checkpeer on

pam_password_prohibit_message Please use Wiki to change your password

bind_policy soft
nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,clamav,couchdb,daemon,dhcpd,freerad,games,gdm,gnats,haldaemon,hplip,irc,kernoops,klog,libuuid,list,lp,mail,man,mcn,messagebus,michael,mysql,news,ntp,ntpd,openldap,pdns,polkituser,postfix,proxy,pulse,root,saned,sftp,snmp,speech-dispatcher,sshd,sync,sys,syslog,uml-net,uucp,vde2-net,www-data
-----------------------------------------

Just changing ssl from 'off' to 'on' made me have the issue.... and reverting it back to 'off' made it work again....

Hope this helps

Same problem here. Only sudoers from the local sudoers file are recognized. Also the setting sin ldap.conf (/etc/ldap.conf and /etc/ldap/ldap.conf were not recognized - sudoers_debug made no change, no debug output).

I fixed a part of the problem by recompiliing sudo-ldap from source:

apt-get build-dep sudo-ldap
apt-get source sudo-ldap
cd sudo-1.7.0
./configure && make && make install

After that the settings in ldap.conf are recognized. I can see the debug output which gives me "sudo: Command allowed". The entries are found and everything should work fine.

But when I'm forced to enter my password sudo tells me that it's wrong.

Any advice?

Made a mistake in my previous post.

I configured sudo with

./configure --with-ldap

Now I configured it with

./configure --with-ldap --with-pam

and everything works fine!!!

Hope it works for you too.

Philipp Lies (philipp-lies) wrote :

Workaround confirmed on latest karmic x86_64, recompiling sudo-ldap fixed problem.

John Affleck (lists+launchpad) wrote :

I think we're talking about two separate problems. I recompiled sudo-ldap as above, and still receive:
sudo: setresuid(user_uid, user_uid, ROOT_UID): Operation not permitted
..when I have ssl enabled in /etc/ldap.conf

In my case, the sudoers file is always local and contains:
<username> ALL=(ALL) ALL # Not literally <username>

When I have:
uri ldaps://192.168.1.1/
ssl on
..in /etc/ldap.conf, the above user will receive the above error.
When I change that to:
uri ldap://192.168.1.1/
ssl off
..it goes back to working again.

Matthias/Philipp - Are you using LDAP over SSL or just vanilla LDAP ? Are the users present in /etc/passwd, or only via LDAP ?

@John: You're right, I'm not using SSL, my solution was just for the "sudo not working with ldap in general" issue. Users are only present in the LDAP directory, not in /etc/passwd!

Philipp Lies (philipp-lies) wrote :

I use vanilla LDAP and the users are only available via LDAP, too.

I can confirm this bug on a box updated from 9.04 to 9.10, where both sudo and su worked just fine.

The test user is only in LDAP, and locally (in /etc/groups) member of the "admin" group. If LDAP uses ssl, su/sudo fail, and they work as advertised with a plain connection.

An other effect which is apparently related: If I launch evince with LDAP/ssl, it takes very long (~15 seconds) to start, and then spits out the message

(evince:2541): GLib-WARNING **: getpwuid_r(): failed due to: Permission denied.

Switching to LDAP/plain, it comes up immediately. Probably this is a glibc (?) and not a su(do) bug.

And as unencrypted LDAP is a security risk, this bug is IMHO a critical one.

Alex Mauer (hawke) wrote :

This seems like it may be at least partly related to debian bug #545414

Greg (g6) wrote :

Bug still present as of today.

Changing /etc/slapd on the server from:

SLAPD_SERVICES="ldaps:///"

to:

SLAPD_SERVICES="ldap:/// ldaps:///"

and /etc/ldap.conf on the clients from:

uri ldaps://server.my.lan/
ssl on

to:

uri ldap://server.my.lan/
ssl off

'fixed' the problem for me, where 'fixed' means it is no longer authenticating over ssl and validating the server certificate. Not happy.

Is anyone looking at this?

nsswitch included below

greg@blah:$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

# pre_auth-client-config # passwd: compat
passwd: files ldap
# pre_auth-client-config # group: compat
group: files ldap
# pre_auth-client-config # shadow: compat
shadow: files ldap

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

# pre_auth-client-config # netgroup: nis
netgroup: nis

Rune Philosof (olberd) on 2009-11-17
summary: - NSS using LDAP on Karmic (alpha 4) breaks 'su' and 'sudo'
+ NSS using LDAP on Karmic breaks 'su' and 'sudo'

I still have the issue, I will try on a different install and will
compile the sudo package from the sources.

Actually, sudo is still failling with the message "sudo:
setreuid(ROOT_UID, user_uid): Operation not permitted" when connecting
to an ldaps. Disabling SSL is the only work arround i found so far.

On Sat, Dec 5, 2009 at 4:12 PM, Boris Devouge
<email address hidden> wrote:
> Any news on this issue?
>
> --
> NSS using LDAP on Karmic breaks 'su' and 'sudo'
> https://bugs.launchpad.net/bugs/423252
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “glibc” package in Ubuntu: Confirmed
>
> Bug description:
> On Karmic (alpha 4 plus updates), changing the nsswitch.conf 'passwd' field to anything with 'ldap' as the first item breaks the ability to become root using 'su' and 'sudo' as anyone but root.
>
> Default nsswitch.conf:
>
> passwd:         compat
> group:          compat
> shadow:         compat
>
> matt@box:~$ sudo uname -a
> [sudo] password for matt:
> Linux box 2.6.31-9-server #29-Ubuntu SMP Sun Aug 30 18:37:42 UTC 2009 x86_64 GNU/Linux
>
> matt@box:~$ su -
> Password:
> root@box:~#
>
> Modified nsswitch.conf with 'ldap' before 'compat':
>
> passwd:         ldap compat
> group:          ldap compat
> shadow:         ldap compat
>
> matt@box:~$ sudo uname -a
> sudo: setreuid(ROOT_UID, user_uid): Operation not permitted
>
> matt@box:~$ su -
> Password:
> setgid: Operation not permitted
>
> Modified nsswitch.conf with 'ldap' after 'compat':
>
> passwd:         compat ldap
> group:          compat ldap
> shadow:         compat ldap
>
> matt@box:~$ sudo uname -a
> [sudo] password for matt:
> Linux box 2.6.31-9-server #29-Ubuntu SMP Sun Aug 30 18:37:42 UTC 2009 x86_64 GNU/Linux
>
> matt@box:~$ su -
> Password:
> root@box:~#
>
> The same arrangements in nsswitch.conf work as expected in Jaunty and earlier releases.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/423252/+subscribe
>

Confirmed, still having this issue as well.

The workaround turning ssl off works, however (even if this is not a very fortunate solution).

Rune Philosof (olberd) wrote :

I worked around it by installing nscd..
Why is it that installing this package removes the problem?

Rune Philosof (olberd) wrote :

With nscd installed ssl=on works for me.

This is also a problem with fuse on ltsp. I could not mount local devices when logging on as a ldap user, only as a local user.
getent shadow does not return any ldap users.
nscd workaround also helps in this case.

Changed in sudo (Debian):
status: Unknown → Confirmed
Jay (jay-wharfs) wrote :

Confirmed, I also have this bug.

I can disable ssl or install nscd and it goes away.

Neile Havens (neile-havens) wrote :

NOTE: This is a regression (or design change) from Jaunty.

Installing nscd gets rid of this error message when trying to sudo as an ldap user
sudo: setreuid(ROOT_UID, user_uid): Operation not permitted

With nscd installed and ldaps and ssl on, I can sudo as an ldap user. In addition, I can su from an ldap user to a local user. However, I cannot su from a local user to an ldap user.
nhavens@cslab04:/homes.all/linux/nhavens$ su ladmin
Password:
ladmin@cslab04:/homes.all/linux/nhavens$ su nhavens
Password:
setgid: Operation not permitted
ladmin@cslab04:/homes.all/linux/nhavens$

In /etc/ldap.conf, with the following combination, I still get "Operation not permitted"
ldaps://**********
ssl off

The "Operation not permitted" error, when suing from local to ldap users only goes away when I change ldaps://***** to ldap://******

David Tomaschik (matir) wrote :

Is anyone experiencing this bug running an LDAPS server that does NOT have a self-signed certificate? I'm wondering if the issue might be certificate-related, since using plaintext ldap works.

I was not using a self-signed certificate at the time I reported this
bug.

On Jan 17, 2010, at 5:14 PM, David Tomaschik wrote:

> Is anyone experiencing this bug running an LDAPS server that does NOT
> have a self-signed certificate? I'm wondering if the issue might be
> certificate-related, since using plaintext ldap works.
>
> --
> NSS using LDAP on Karmic breaks 'su' and 'sudo'
> https://bugs.launchpad.net/bugs/423252
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “glibc” package in Ubuntu: Confirmed
> Status in “sudo” package in Debian: Confirmed
> Status in “sudo” package in Kairos Linux: New
>
> Bug description:
> On Karmic (alpha 4 plus updates), changing the nsswitch.conf
> 'passwd' field to anything with 'ldap' as the first item breaks the
> ability to become root using 'su' and 'sudo' as anyone but root.
>
> Default nsswitch.conf:
>
> passwd: compat
> group: compat
> shadow: compat
>
> matt@box:~$ sudo uname -a
> [sudo] password for matt:
> Linux box 2.6.31-9-server #29-Ubuntu SMP Sun Aug 30 18:37:42 UTC
> 2009 x86_64 GNU/Linux
>
> matt@box:~$ su -
> Password:
> root@box:~#
>
> Modified nsswitch.conf with 'ldap' before 'compat':
>
> passwd: ldap compat
> group: ldap compat
> shadow: ldap compat
>
> matt@box:~$ sudo uname -a
> sudo: setreuid(ROOT_UID, user_uid): Operation not permitted
>
> matt@box:~$ su -
> Password:
> setgid: Operation not permitted
>
> Modified nsswitch.conf with 'ldap' after 'compat':
>
> passwd: compat ldap
> group: compat ldap
> shadow: compat ldap
>
> matt@box:~$ sudo uname -a
> [sudo] password for matt:
> Linux box 2.6.31-9-server #29-Ubuntu SMP Sun Aug 30 18:37:42 UTC
> 2009 x86_64 GNU/Linux
>
> matt@box:~$ su -
> Password:
> root@box:~#
>
> The same arrangements in nsswitch.conf work as expected in Jaunty
> and earlier releases.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/423252/+subscribe

We use LDAP over TLS via PAM for auth, and use NSSWITCH as well. After upgrade from Hardy -> Jaunty -> Karmic, su no longer functioned, however sudo did work.

Here is what I found. When upgrading to Karmic, keeping our old /etc/pam.d/common-auth failed for su. Putting in the default common-auth from a fresh install of Karmic works.

Old /etc/pam.d/common-auth:
auth sufficient pam_ldap.so debug
auth sufficient pam_unix.so try_first_pass likeauth nullok
auth required pam_deny.so
auth required pam_nologin.so

Baseline Karmic /etc/pam.d/common-auth that works (snippet):
# here are the per-package modules (the "Primary" block)
auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_ldap.so use_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so

Our relavent nsswitch lines:
passwd: files ldap
group: files ldap
shadow: files ldap

Relevant /etc/ldap.conf lines:
ssl start_tls
tls_checkpeer no

So, after "fixing" the common-auth file, su began working for us. Hope that is helpful.

Fabien (fabien-ubuntu) wrote :

I have the same problem when using tls with a fresh install. But, installing nscd doesn't solve the problem and I have the original comme-auth file...

tags: added: glucid
Andrew Pollock (apollock) wrote :

I was seeing this problem with sudo/sudo-ldap 1.7.0-1ubuntu3 in Lucid. I didn't have nscd installed. Once I installed it, everything came good.

Jay (jay-wharfs) wrote :

Any progress with this ?
LDAP integration is crucial to so many sites, this is a major blocker for me at present. Would hate to see this end up also in Lucid.

Rune Philosof (olberd) wrote :

I am running a 64bit karmic.
Is this restricted to 64bit karmic or also present on 32bit karmic?

On my computer libnss_ldap is provided by ia32-libs:
rune@rune-laptop:~$ dpkg -S libnss_ldap
ia32-libs: /usr/lib32/libnss_ldap.so
ia32-libs: /lib32/libnss_ldap-2.10.1.so
ia32-libs: /lib32/libnss_ldap.so.2

Could it not be this library that is causing the problem?
Does it change anything to install libnss-ldap which provides the 64bit version?

Maybe the bug should be against libnss-ldap?

Hark (ubuntu-komkommerkom) wrote :

Same problem here with LDAP over TLS. Enabling nscd solves the problem, but as we have a history of crashing nscd daemons this isn't a reliable solution.

Christoph Cullmann (cullmann) wrote :

We have the same problem at our company, since Karmic Ubuntu is quiet unusable for us :/
Would really appreciate a fix for Lucid or at least a better workaround then running nscd, which here doesn't help at all :(

bl8n8r (bl8n8r-gmail) wrote :

Looks like it's still busted with latest 'aptiude upgrade' in karmic 64bit Server.
I tried to work-around by copying /lib/libnss_ldap-2.8.so /lib/libnss_ldap.so.2 and /usr/lib/libnss_ldap.so
from Jaunty host to karmic host (as questioned above) but 'su -' still failed.

from root, 'su -' to a localuser is fine, but if we 'su -' from localuser to ldap user we get errors
[root@karmic64 ~]
# su - localuser
localuser@karmic64:~$ su - ldap_user384
Password:
setgid: Operation not permitted

if we 'su -' from root to an ldap user, it works OK
[root@karmic64 ~]
# su - ldap_user384
No directory, logging in with HOME=/
[ldap_user384@karmic64 /]
$

can also 'su -' from ldap user to local user successfully
[ldap_user384@karmic64 /]
$ su - localuser
Password:
localuser@karmic64:~$

- nscd is running but does not fix
- ldap is running over SSL
- 'ssl off' in /etc/ldap.conf and /etc/ldap/ldap.conf does not fix problem
- nsswitch.conf has "files ldap" for group, shadow and passwd

Christoph Cullmann (cullmann) wrote :

Nice that others can reproduce it too, but bad that no fix seems to be available. Lucid is coming up soon as LTS and will be completly unusable for any company using LDAP authentification......

Kees Cook (kees) wrote :

It would help to understand if the problem is with eglibc, sudo, or libnss-ldap.

affects: glibc (Ubuntu) → eglibc (Ubuntu)
Changed in eglibc (Ubuntu Karmic):
status: New → Invalid
Changed in eglibc (Ubuntu Lucid):
status: Confirmed → Invalid
Changed in eglibc (Ubuntu Karmic):
status: Invalid → New
affects: eglibc (Ubuntu Karmic) → sudo (Ubuntu Karmic)
Changed in sudo (Ubuntu Lucid):
status: Invalid → New
Matt Kassawara (ionosphere80) wrote :

Since 8.10 (Intrepid), the Ubuntu Server Guide section regarding LDAP authentication references the auth-client-config and libnss-ldap packages. However, following these instructions when using LDAP with TLS breaks various authentication functions in 9.10 (Karmic). After determining this issue still exists (nearly 7 months later) in the beta release of 10.04 (Lucid), I began looking for new workarounds. I found a package first available in Karmic, nslcd, which also installs libnss-ldapd, nscd, and several other dependencies. All of the latter packages exist in the 'universe' component. I removed the nscd package for testing purposes. Using the configuration provided in the opening post for this bug report, 'su' and 'sudo' now function properly. Although I'm still unsure as to the exact origin of this issue (e.g., eglibc, libnss-ldap, sudo, etc.), replacing libnss-ldap with libnss-ldapd probably provides the core of this workaround.

Bug still present under the latest lucid beta.

Mathias Gug (mathiaz) on 2010-03-30
Changed in sudo (Ubuntu Lucid):
importance: Undecided → Medium
Changed in libnss-ldap (Ubuntu Lucid):
importance: Undecided → Medium
Changed in sudo (Kairos Linux):
assignee: nobody → Philipp Kaluza (pixelpapst)
importance: Undecided → High
status: New → Confirmed
Thierry Carrez (ttx) on 2010-04-21
Changed in sudo (Ubuntu Lucid):
assignee: nobody → Mathias Gug (mathiaz)
Mathias Gug (mathiaz) on 2010-04-27
Changed in eglibc (Ubuntu Karmic):
status: New → Invalid
Changed in eglibc (Ubuntu Lucid):
status: New → Invalid
Changed in libnss-ldap (Ubuntu Karmic):
status: New → Invalid
Changed in libnss-ldap (Ubuntu Lucid):
status: New → Invalid
Changed in sudo (Ubuntu Karmic):
status: New → Invalid
Changed in sudo (Ubuntu Lucid):
status: New → Invalid
Changed in libgcrypt11 (Ubuntu Karmic):
importance: Undecided → Medium
status: New → Triaged
Changed in libgcrypt11 (Ubuntu Lucid):
importance: Undecided → Medium
status: New → Triaged
Mathias Gug (mathiaz) on 2010-04-27
summary: - NSS using LDAP on Karmic breaks 'su' and 'sudo'
+ NSS using LDAP+SSL breaks setuid applications like su and sudo
Mathias Gug (mathiaz) on 2010-04-27
description: updated
Changed in ubuntu-release-notes:
status: New → Confirmed
tags: added: regression-release
Changed in libgcrypt11 (Ubuntu Lucid):
milestone: none → lucid-updates
Loïc Minier (lool) on 2010-04-28
Changed in ubuntu-release-notes:
status: Confirmed → Fix Released
Mathias Gug (mathiaz) on 2010-04-28
Changed in ubuntu-release-notes:
status: Fix Released → Confirmed
Loïc Minier (lool) on 2010-04-29
Changed in ubuntu-release-notes:
status: Confirmed → Fix Released
Rune Philosof (olberd) on 2010-04-29
Changed in ubuntu-release-notes:
status: Fix Released → Confirmed
Steve Langasek (vorlon) on 2010-04-29
Changed in ubuntu-release-notes:
status: Confirmed → Fix Released
Changed in libgcrypt11 (Debian):
status: Unknown → Confirmed
tags: added: patch
summary: - NSS using LDAP+SSL breaks setuid applications like su and sudo
+ NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2
+ suexec, and atd
Changed in eglibc (Ubuntu Maverick):
status: New → Invalid
Changed in libgcrypt11 (Ubuntu Maverick):
importance: Undecided → Medium
milestone: none → maverick-updates
status: New → Triaged
Changed in sudo (Ubuntu Maverick):
status: New → Invalid
Changed in libgcrypt11 (Ubuntu):
status: Triaged → Confirmed
Changed in libgcrypt11 (Ubuntu Karmic):
status: Triaged → Won't Fix
Changed in libgcrypt11 (Ubuntu Lucid):
status: Triaged → Confirmed
Changed in libgcrypt11 (Ubuntu Maverick):
status: Triaged → Confirmed
Changed in libgcrypt11 (Ubuntu Maverick):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Changed in libgcrypt11 (Ubuntu Lucid):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Changed in libnss-ldap (Ubuntu Maverick):
status: New → Confirmed
tags: added: precise
Steve Langasek (vorlon) on 2012-04-25
no longer affects: openldap (Ubuntu)
no longer affects: openldap (Ubuntu Karmic)
no longer affects: openldap (Ubuntu Lucid)
Steve Langasek (vorlon) on 2012-04-25
no longer affects: openldap (Ubuntu Maverick)
Changed in gnutls26 (Debian):
status: Unknown → New
93 comments hidden view all 173 comments
Arthur de Jong (adejong) wrote :

If you are seeing something like:
  Warning: /lib/x86_64-linux-gnu/libnss_ldap.so.2: undefined symbol: _nss_ldap_enablelookups (probably older NSS module loaded)
It means that you probably have libnss-ldap installed instead of libnss-ldapd (note the extra d). Using nslcd works best with libnss-ldapd and libpam-ldapd.

ksosez (methone) wrote :

This is busted in 12.04 and we cant use sudo with LDAP and SSL.

Kind of a show stopper when it comes to enterprise deployments

I

I my recent experience, installing libnss-ldapd and libpam-ldapd (which in turn install nslcd and uninstall libnss-ldap and libpam-ldap) fixes the problem on 11.10 and 12.04.

-sbi

Craig White (craig-white) wrote :

See here's the deal...

Yes, the problem seems to occur with starttls being enabled but given the choice...

- libnss-ldap
- libpam-ldap
- nscd

or

- libnss-ldapd
- libpam-ldapd
- nslcd

The first one fails if starttls is used to connect to the ldap server
The second one fails to respect 'pam_check_host_attr yes' setting

So I have problems no matter what I do. It's time for Ubuntu to clean this up as I was able to function w/ Lucid (libnss-ldap/libpam-ldap/nscd) but have only 2 lousy choices in Precise

Arthur de Jong (adejong) wrote :

You can replace "pam_check_host_attr yes" with
  pam_authz_search (&(objectClass=posixAccount)(uid=$username)(|(host=$hostname)(host=$fqdn)(host=\\*)))
See the nslcd.conf manual page for more details (the 0.7 series doesn't have the fqdn value yet).

Btw, you can use libpam-ldap fine together with libnss-ldapd if you prefer.

Also note that nslcd is no replacement for nscd. nslcd doesn't do much caching and nscd (or unscd) can still be used to reduce the load on your LDAP server.

The only real things that are missing in nss-pam-ldapd are nested groups and LDAP password policies. Patches are welcome ;)

Craig White (craig-white) wrote :

adejong@138

Put that entry into /etc/nslcd.conf as you suggested (and as the man page suggests) and removed my 'host' attribute which should prevent me from logging into my upgraded 12.04 system but it didn't. (NSCD & NSLCD running, libnss-ldapd and libpam-ldapd installed & configured)

Obviously I can't expect the pam_check_host_attr in /etc/ldap.conf to work with this configuration but I did hope that the nslcd.conf would work and prevent me from being able to login - it didn't. This was after a reboot so I'm reasonably sure that nothing was cached in nslcd or nscd that would have impacted.

Arthur de Jong (adejong) wrote :

craig-white@139

Please file a bug against nslcd to track the problem with pam_authz_search.

Also, in general, bug reports for any missing features are welcome.

description: updated
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libgcrypt11 - 1.5.0-3ubuntu1

---------------
libgcrypt11 (1.5.0-3ubuntu1) quantal; urgency=low

  * Do not call global_init when setting thread callbacks (LP: #423252)
 -- Adam Stokes <email address hidden> Tue, 15 May 2012 13:56:17 -0400

Changed in libgcrypt11 (Ubuntu):
status: Confirmed → Fix Released
Adam Stokes (adam-stokes) wrote :

Precise debdiff for SRU

Stéphane Graber (stgraber) wrote :

Uploaded your debdiff to precise-proposed with two small changes:
 - Targeted precise-proposed instead or precise
 - Changed version to -0ubuntu0.1 instead of -0ubuntu1

1 comments hidden view all 173 comments
Adam Stokes (adam-stokes) wrote :

natty-proposed debdiff

Changed in libgcrypt11 (Ubuntu Maverick):
status: Confirmed → Won't Fix
Changed in libgcrypt11 (Ubuntu Precise):
status: New → Fix Committed
Changed in libgcrypt11 (Ubuntu Oneiric):
status: New → Fix Committed
Changed in libgcrypt11 (Ubuntu Natty):
status: New → Fix Committed

Hello Matt, or anyone else affected,

Accepted libgcrypt11 into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Martin Pitt (pitti) wrote :

Hello Matt, or anyone else affected,

Accepted libgcrypt11 into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Martin Pitt (pitti) wrote :

Hello Matt, or anyone else affected,

Accepted libgcrypt11 into natty-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Ballock (ballock) wrote :

Hello, Martin.

Any chance of getting that for lucid?

Thank you in advance!

Stéphane Graber (stgraber) wrote :

Yes, it'll be SRUed for lucid too, I'm just waiting for Adam to finish preparing the debdiff and I'll review and upload it to lucid-proposed.

mcguire (jonathand131-gmail) wrote :

Hello Martin,

I was affected by the bug ann I confirm that using the latest packages from proposed solves the problem with my company's setup for LDAP.

Thanks a lot.
Regards.

Clint Byrum (clint-fewbar) wrote :

Hi mcguire.

Which release of Ubuntu do the updated packages solve the problem on for you? There are fixes available for natty, oneiric, and precise.

Thanks!

mcguire (jonathand131-gmail) wrote :

Ubuntu 12.04 Precise

tags: added: verification-done verification-done-precise
Adam Stokes (adam-stokes) wrote :

Lucid-proposed debiff

Changed in libgcrypt11 (Ubuntu Lucid):
status: Confirmed → Fix Committed
Steve Langasek (vorlon) wrote :

not "committed" until it's available in -proposed

Changed in libgcrypt11 (Ubuntu Lucid):
status: Fix Committed → In Progress
Chris Halse Rogers (raof) wrote :

Hello Matt, or anyone else affected,

Accepted libgcrypt11 into lucid-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in libgcrypt11 (Ubuntu Lucid):
status: In Progress → Fix Committed
tags: removed: verification-done
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libgcrypt11 - 1.5.0-3ubuntu0.1

---------------
libgcrypt11 (1.5.0-3ubuntu0.1) precise-proposed; urgency=low

  * Do not call global_init when setting thread callbacks (LP: #423252)
 -- Adam Stokes <email address hidden> Wed, 16 May 2012 13:35:06 -0400

Changed in libgcrypt11 (Ubuntu Precise):
status: Fix Committed → Fix Released
Colin Watson (cjwatson) on 2012-06-01
tags: removed: verification-done-precise
Ballock (ballock) wrote :

Hey, raof,

I have tested the lucid-proposed version and it works fine. sudo no longer segfaults.

Thanks for the package! I am waiting for it to arrive at lucid-updates!

Steve Langasek (vorlon) on 2012-06-14
tags: added: verification-done-lucid
Ballock (ballock) wrote :

Any chance of it getting to lucid-updates anytime soon?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libgcrypt11 - 1.4.4-5ubuntu2.1

---------------
libgcrypt11 (1.4.4-5ubuntu2.1) lucid-proposed; urgency=low

  * Do not call global_init when setting thread callbacks (LP: #423252)
 -- Adam Stokes <email address hidden> Thu, 24 May 2012 16:31:52 -0400

Changed in libgcrypt11 (Ubuntu Lucid):
status: Fix Committed → Fix Released
Ballock (ballock) wrote :

Thank you!

The patch applied to libgcrypt breaks other software: https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798

Adam Stokes (adam-stokes) wrote :

After reviewing this bug again I've outlined a possible course of action:

a) Revert global_init patch in all supported distro's
b) Lucid users continue to use the nscd workaround.
c) Precise, Quantal, etc - rebuild gnutls without --with-libgcrypt in order to make use of nettle.

Unfortunately, the version of gnutls in Lucid is older than the required gnutls version for nettle support. So I do not believe there will be much that we can do as far as a supportable option is concerned.

I will need to speak with some other engineers about getting option c pushed through[1].

[1] http://pad.lv/926350

Howard Chu (hyc) wrote :

Forcing use of nscd is a non-starter at many sites. Aside from cache staleness issues, and nscd's well known instability, there's also the issue that nscd doesn't intercept get*ent enumerations so things will still crash depending on which nsswitch functions an app calls.

It would make sense to use nettle on the newer releases that support it, but keep the patch in place otherwise.

Howard Chu (hyc) wrote :

This additional patch fixes the crash in bug#1013798.

Howard Chu (hyc) wrote :

Oops. The attachment in comment#166 includes the patch in #73, it is not incremental.

Adam Stokes (adam-stokes) wrote :

Thanks Howard,

I'll get this reviewed and tested this week.

Adam

no longer affects: eglibc (Ubuntu)
no longer affects: libnss-ldap (Ubuntu)
no longer affects: sudo (Ubuntu)
Adam Stokes (adam-stokes) wrote :

Are there any testers for Natty, Oneiric for this issue? I'd like to try and get this one closed out.

Thanks
Adam

The fix for this bug has been awaiting testing feedback in the -proposed repository for oneiric for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

tags: added: removal-candidate
carloslp (carloslp) wrote :

See http://bugs.debian.org/368297 http://bugs.debian.org/658896 for an alternative patch to fix this bug that don't introduced any regression (LP: #1013798).

The patch applied to libgcrypt (no-global-init-thread-callbacks.diff) should be reverted and the following patch http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=135;filename=fix-dropping-privileges-by-libgcrypt-secmem.diff;att=2;bug=368297 should be applied to OpenLDAP.

carloslp (carloslp) wrote :

Actual comment on the Debian bug history with the patch and the explanation: http://bugs.debian.org/658896#104

Changed in gnutls26 (Debian):
status: New → Confirmed
dino99 (9d9) on 2013-05-04
Changed in eglibc (Ubuntu Natty):
status: New → Invalid
Changed in eglibc (Ubuntu Oneiric):
status: New → Invalid
Changed in libgcrypt11 (Ubuntu Natty):
status: Fix Committed → Invalid
Changed in libgcrypt11 (Ubuntu Oneiric):
status: Fix Committed → Invalid
Changed in libnss-ldap (Ubuntu Natty):
status: New → Invalid
Changed in libnss-ldap (Ubuntu Oneiric):
status: New → Invalid
Changed in sudo (Ubuntu Natty):
status: New → Invalid
Changed in sudo (Ubuntu Oneiric):
status: New → Invalid
dino99 (9d9) wrote :

Changes made above as per eol https://wiki.ubuntu.com/Releases

Changed in libnss-ldap (Ubuntu Maverick):
status: Confirmed → Invalid
Displaying first 40 and last 40 comments. View all 173 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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