Bug#658896: not fixed - please don't ignore this bug for wheezy

[Brian Kroth]

Sorry for the late reply, I've been out on leave and for some reason wasn't getting the responses to these bugs even though I've subscribed.

There are two separate issues as I see them:

When using starttls or ldaps:// in a pam_ldap.conf* file, then

1) If I try to do a su non-root-user, then I get a setgid error:

# /bin/su - bkroth
Password:
setgid: Operation not permitted



2) If I try to sudo (not sudo-ldap), it fails with a "setresuid error":

# sudo -s
bpkroth@faitest64's sudo password:
sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted
sudo: unable to open /var/lib/sudo/bpkroth/1: Operation not permitted
sudo: unable to set supplementary group IDs: Operation not permitted
sudo: unable to execute /bin/bash: Operation not permitted

This *was* working in squeeze just fine.



Also, libpam-ldapd does *not* solve this problem, for two reasons:

a) It doesn't actually fix the setresuid problem (2)!  I've tested this.
<edit>

</edit>










Thanks,
Brian

I hate to dredge this up again given the release announcement, but there's been a lot of confusion about this and related bugs and I think our particular problem was lost. As was correctly reported, this was an error in squeeze as well, and is not our primary concern (though if it were fixed as well, I wouldn't be upset :). This is part of the bug that I'm very concerned about. We depend upon it for a number of different things, including automated monitoring and repair, authenticating users to specific services such as dovecot, etc. Actually, I take that back. It seems one of the recent updates fixed this part at least. b) libpam-ldapd can only use a single global configuration file. We need libpam-ldap's (no d) ability to reference different pam_ldap.conf files from different /etc/pam.d/service files in order to specify different ldap filters, base ou lookups, etc. settings for service specific authentications. For instance, dovecot is configured to only accept users with "filter custom_acl_attr=mail", whereas sudo (on that same machine) is configured to only authenticate users in an "ou=Sudo,ou=People" part of the ldap tree. There are several other examples of this such as cron, ssh, and others. Note, we also make use of pam_access for certain restrictions, but this is an incomplete solution since it doesn't allow attribute or ou ldap filters. On my my colleagues (Simon Fondrie-Teitler) tells me that one or more patches were able to fix problem (2), though I've been out on leave and don't recall which ones exactly so I'll let him comment with specific details on that. Please let us know what we can help to do to fix this. We really can't move forward on wheezy in our environment without it.

signature.asc
Description: Digital signature