--On Tuesday, November 14, 2006 6:28 PM -0800 Steve Langasek <[EMAIL PROTECTED]> wrote:

On Tue, Nov 14, 2006 at 05:07:39PM -0800, Quanah Gibson-Mount wrote:
>> [19:07] Howard Chu: that's the wrong fix
>> [19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage.
>> [19:09] Quanah: so this patch doesn't really fix anything?
>> [19:09] Howard Chu: probably not.

> Regardless of the merits of OpenLDAP reading dotfiles on library
> initialization without a flag (er), libnss-ldap should probably get
> that fix, and libpam-ldap too while we're at it.

Okay, it is LDAPNOINIT (rather than NOINIT).

But Howard further clarifies that as long as nss/pam_ldap fully specify
their ldap.conf file to use, the users' .ldaprc file will never be read.
So the only time this is an issue is if someone hasn't really configured
nss/pam properly, and I assume that debian does things right.

I don't accept this reasoning.  The penalty to an admin for configuring
their software "wrong" -- where "wrong" means "assuming that options left
as defaults will keep the default values" -- should not be a root security
hole.

Huh? As long as the admin has told nss/pam ldap to explicitly use an ldap configuration file, that is what it will use, regardless of what is in the user's .ldaprc file, i.e., the defaults will not be over ridden by whatever is in their local file.

I agree that libnss-ldap and libpam-ldap should be using this LDAPNOINIT
flag, now that we know it exists.  Cc:ing the original bug report, so that
Stephen can look into that.  But this should still be *in addition to* the
suid check, not *instead of* it, because there may be suid applications
using libldap by other means because they assume it's secure.


Based on my discussions with Howard, I don't think your patch does what you think it does.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to