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.

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.

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

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 :).

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

# sudo -s
bpkroth at 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.

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.

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>
Actually, I take that back.  It seems one of the recent updates fixed 
this part at least.
</edit>


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.

Thanks,
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20130429/68a1d596/attachment.pgp>