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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
