On Tue, Jun 10, 2008 at 03:25:33AM -0700, Russ Allbery wrote:
This was a while back, so my memory may be wrong on the details. Steve
might remember more.
I think your memory is probably better than mine here, I didn't remember
half of the details until I read them again in your message. :)
So
Steve Langasek wrote:
I think your memory is probably better than mine here, I didn't remember
half of the details until I read them again in your message. :)
So do we have some sort of reproducible parser crash in libldap here, then?
Is there a bug report open about this (with Debian or
Brian May [EMAIL PROTECTED] writes:
Is there anyway to configure the ldap libraries not to read from
$HOME/.ldaprc?
Well, you can set LDAPNOINIT or LDAPCONF. It's even documented in
ldap.conf(5):
Users may create an optional configuration file, ldaprc or .ldaprc, in
their home
Russ Allbery wrote:
I tried to convince upstream that this was a security concern and got
yelled at for my trouble until I gave up (although to be fair, upstream
did agree at least that reading files out of the current working directory
was a broken idea and they wouldn't do it if they were
Brian May [EMAIL PROTECTED] writes:
In my case, it looks like the NSS module is getting its certificates
based on the defaults in $HOME/.ldaprc. I expect this, because I have
the certificates configured in /etc/ldap/ldap.conf and nowhere else.
This is presumable why it is segfaulting, because
Hello,
I posted this to my local mailing list, but got no answer. This is as on
Debian/etch.
It would appear sudo, a secure program, is reading ldap configuration
from an insecure file, when pam/nss is configured to use ldap.
[EMAIL PROTECTED]:~$ sudo -k
[EMAIL PROTECTED]:~$ mv .ldaprc.bad
6 matches
Mail list logo
