Broken su/sudo/whatever - breaks systems - up goes the severity

Joerg Jaspert joerg at debian.org
Wed Oct 24 12:43:08 UTC 2012


severity 658739 grave
thanks

Hi

The bug log is a bit long and contains some things not really useful, 
so let me
give another summary here please.

Have ldap servers somewhere, serving you your users and groups.

Setup your libnss and pam access like this:
--------------
base dc=whatever
uri ldap://serverb.../ ldap://servera.../
ldap_version 3
rootbinddn cn=admin,dc=whatever
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/ssl/ca.cert
--------------

In other words, access your ldap server using ssl.

getent passwd/group all works.
Login works.

Try su to another user.

You will see, in auth.log:

Oct 24 12:25:23 AAAAA su[12964]: pam_unix(su:auth): authentication 
failure; logname=user uid=1011 euid=1011 tty=/dev/pts/10 ruser=user 
rhost=  user=targetuser
Oct 24 12:25:23 AAAAA su[12964]: Successful su for targetuser by user
Oct 24 12:25:23 AAAAA su[12964]: + /dev/pts/10 user:targetuser
Oct 24 12:25:23 AAAAA su[12964]: bad group ID `53' for user 
`targetuser': Operation not permitted

And the su you started errors out and you are back as your normal user.

Now, go and change the above nss/pam config to NOT have the "ssl 
start_tls" line. No other change.
and su again.

You will end up, no trouble, as the targetuser.


Maybe the rebuild without gcrypt is a solution. I don't know, I have no 
idea what other functionality
then might be missing. Ignoring this sure is not. It might also be that 
the bug originates elsewhere, though
don't ask me where. But I know that not having this fixed in wheezy 
(and if possible in squeeze too) would
be a real shame. SSL secured ldap servers are not really uncommon, 
after all there are accounts and passwords
in there...

-- 
bye Joerg



More information about the Pkg-gnutls-maint mailing list