Bugzilla – Bug 511
ldap issues since sudo v 1.8 (affecting local users, and ldap users)
Last modified: 2011-10-22 19:44:34 MDT
On Debian testing (wheezy) Setup working with sudo v 1.7.*, with ldap users, ldap groups and ldap sudo rules. Two strange behaviors when upgrading from sudo v 1.7 to v 1.8. The first one, concerning the activation of ldap netgroups, and second one concerning the use of ssl in the ldap conf. These two behaviors occur whether the user is in the ldap or local files, with local sudo rules or ldap sudo rules. First one about netgroup: $ cat /etc/nsswitch.conf ... passwd: files ldap db group: files ldap db shadow: files ldap hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: ldap sudoers: files ldap ... ldapuser@host:~$ sudo -l Matching Defaults entries for ldapuser on this host: env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User ldapuser may run the following commands on this host: (root) NOPASSWD: ALL ldapuser@host:~$ sudo -s sudo: unable to set gid to runas gid 0: Opération non permise sudo: unable to execute /bin/bash: Operation not permitted ldapuser@host:~$ The ldapuser does not belong to any netgroup, but when deactivating ldap netgroups in nsswitch.conf: ldapuser@host:~$ cat /etc/nsswitch.conf ... netgroup: files ... ldapuser@host:~$ sudo -s root@host:/home/ldapuser# Second one about ldap ssl (with netgroup deactivated): $ grep ^uri /etc/sudo-ldap.conf uri ldap://server1.localdomain/ ldap://server2.localdomain/ $ ldapuser@host:~$ sudo -l Matching Defaults entries for ldapuser on this host: env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User ldapuser may run the following commands on this host: (root) NOPASSWD: ALL ldapuser@host:~$ sudo -s root@host:/home/ldapuser# Now, let's use ssl: $ grep ^uri /etc/sudo-ldap.conf uri ldaps://server1.localdomain:636/ ldaps://server2.localdomain:636/ $ ldapuser@host:~$ sudo -l Matching Defaults entries for ldapuser on this host: env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User ldapuser may run the following commands on this host: (root) NOPASSWD: ALL sudo: setuid(0): Opération non permise ldapuser@host:~$ sudo -s sudo: unable to change to runas gid: Opération non permise ldapuser@host:~$ Now, when switching back to a v 1.7 version (with ldap netgroup and ldap ssl): ldapuser@host:~$ sudo -V Sudo version 1.7.4p4 ldapuser@host:~$ sudo -s root@host:/home/ldapuser# Regards.
The problem is that ldap_initialize() is modifying the effective uid. Before the call to ldap_start_tls_s(), the euid is 0, aftter ldap_start_tls_s(), the effective and saved uids are the same as the real uid. Because of this, sudo is unable to change the uid or gid later on. I've added a workaround for sudo 1.8.3 but this really seems like an LDAP bug in Debian. Please try ftp://ftp.sudo.ws/pub/sudo/beta/sudo-1.8.3rc4.tar.gz There will be matching .deb files for 1.8.3rc4 on the ftp site in an hour or two.
It looks like the root of the problem liest in libgcrypt, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566351
(In reply to comment #1) > The problem is that ldap_initialize() is modifying the effective uid. > Before the call to ldap_start_tls_s(), the euid is 0, aftter > ldap_start_tls_s(), the effective and saved uids are the same as the > real uid. Because of this, sudo is unable to change the uid or gid > later on. > > I've added a workaround for sudo 1.8.3 but this really seems like an > LDAP bug in Debian. Please try > ftp://ftp.sudo.ws/pub/sudo/beta/sudo-1.8.3rc4.tar.gz > > There will be matching .deb files for 1.8.3rc4 on the ftp site in an > hour or two. Your workaround works fine for me. With tls used and ldap netgroups declared in nsswitch.conf: ldapuser@host:~$ sudo -V Sudo version 1.8.3.rc4 ldapuser@host:~$ sudo -s root@host:/home/ldapuser#
Sudo 1.8.3 is out now which has this fixed.