Let me point out my non-technical, management-like point of view to this: For my company it would have been a discussable way to put Ubuntu LTS with paid support to a row of our Desktops. But with this issue it is a complete nogo... Rating this as a "high" issue isn't going far enough, for enterprises this is a major blocker aka. showstopper. I would have thought that this would be the utmost interest for Canonical, 'cause supportcontracts is what their business is build upon.
I'm not technically skilled to point to a solution for this and I respect the licensing problem and that nobody wants multiple sets of ldap client libraries. All I want to say is: There must be a solution to this kind of issues to get enterprises to buy support for Ubuntu. -- You received this bug notification because you are a member of Tieto, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/423252 Title: NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec, and atd Status in Release Notes for Ubuntu: Fix Released Status in “eglibc” package in Ubuntu: Invalid Status in “libgcrypt11” package in Ubuntu: Confirmed Status in “libnss-ldap” package in Ubuntu: Invalid Status in “sudo” package in Ubuntu: Invalid Status in “eglibc” source package in Lucid: Invalid Status in “libgcrypt11” source package in Lucid: Confirmed Status in “libnss-ldap” source package in Lucid: Invalid Status in “sudo” source package in Lucid: Invalid Status in “eglibc” source package in Maverick: Invalid Status in “libgcrypt11” source package in Maverick: Confirmed Status in “libnss-ldap” source package in Maverick: Confirmed Status in “sudo” source package in Maverick: Invalid Status in “eglibc” source package in Karmic: Invalid Status in “libgcrypt11” source package in Karmic: Won't Fix Status in “libnss-ldap” source package in Karmic: Invalid Status in “sudo” source package in Karmic: Invalid Status in “gnutls26” package in Debian: Unknown Status in “libgcrypt11” package in Debian: Confirmed Status in “openldap” package in Debian: New Status in “sudo” package in Debian: Confirmed Status in “sudo” package in Kairos Linux: 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. 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/423252/+subscriptions -- Mailing list: https://launchpad.net/~tieto Post to : [email protected] Unsubscribe : https://launchpad.net/~tieto More help : https://help.launchpad.net/ListHelp
