openldap-bugs June 2008

openldap-bugs@openldap.org

46 participants
176 discussions

Re: (ITS#5355) back-meta calls back-ldap directly
by vorlon＠debian.org 29 Jun '08

29 Jun '08

This bug is marked as fixed in 2.4.8, but I still see the same problem in the test suite in 2.4.10. Trying to start slapd with back-meta gives: /home/devel/openldap/build-area/openldap2.3-2.4.10/debian/build/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.4.so.2: undefined symbol: slap_idassert_parse_cf Is this a regression since 2.4.8? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 28 Jun '08

28 Jun '08

Howard Chu wrote: > unix.gurus(a)gmail.com wrote: >> If someone wants to accept or comment on what needs fixing in the >> patch below, that would help me to generate the rest of the patches: >> ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806… > > In back-monitor/database.c you don't need to normalize the DNs before > comparing them. The stored values are already Prettied, so all you need is to > use a case-insensitive compare here. Duh. Or just compare a->a_vals and be->be_suffix instead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 28 Jun '08

28 Jun '08

unix.gurus(a)gmail.com wrote: > If someone wants to accept or comment on what needs fixing in the > patch below, that would help me to generate the rest of the patches: > ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806… In back-monitor/database.c you don't need to normalize the DNs before comparing them. The stored values are already Prettied, so all you need is to use a case-insensitive compare here. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5579) Interaction of ppolicy attributes
by hyc＠symas.com 28 Jun '08

28 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.10 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.97.25.132) > > > If an account becomes locked due to excessive failed authentications, its entry > will contain the attributes pwdFailureTime and pwdAccountLockedTime. If the > account is subsequently unlocked by setting a new password, all values of those > attributes are automatically removed. However, if the password is left alone and > the account is unlocked by removing pwdAccountLockedTime, values remain in > pwdFailureTime. This means that a single authentication failure will immediately > lock the account again. > > pwdFailureTime cannot be modified directly, so I think there is a case for > clearing it when pwdAccountLockedTime is cleared explicitly. Technically, you're not supposed to be able to modify pwdAccountLockedTime directly either. The current behavior is a temporary hack. The only legitimate way to remove those attributes is by setting a new password. I'm rejecting this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 28 Jun '08

28 Jun '08

unix.gurus(a)gmail.com wrote: > I've uploaded a patch that adds an equality matching rule to the > schema for olcRootDN and olcSchemaDN so that the normalization matches > the schema. These attributes are already normalized wherever they are > generated, and their normalized values are used in bvmatches, so > removing the nvals instead of modifying the schema would result extra > normalization calls later. > ftp://ftp.openldap.org/incoming/sean-burford-rootdn-080628.patch Committed, thanks. > If someone wants to accept or comment on what needs fixing in the > patch below, that would help me to generate the rest of the patches: > ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806… If it makes life easier, we can add the DN eq rule to monitorContext and configContext. Since they're OpenLDAP-specific attributes we can make this change without any repercussions. IMO, it really needs to be added to namingContexts since that's multivalued. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 28 Jun '08

28 Jun '08

I've uploaded a patch that adds an equality matching rule to the schema for olcRootDN and olcSchemaDN so that the normalization matches the schema. These attributes are already normalized wherever they are generated, and their normalized values are used in bvmatches, so removing the nvals instead of modifying the schema would result extra normalization calls later. ftp://ftp.openldap.org/incoming/sean-burford-rootdn-080628.patch If someone wants to accept or comment on what needs fixing in the patch below, that would help me to generate the rest of the patches: ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806… -- Thanks, Sean Burford

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 28 Jun '08

28 Jun '08

I've uploaded a tiny patch that checks the return code from structural_class() in config_build_entry() and outputs an error message if it fails. This makes it easier to debug structural_class() failures before too much other code is run: ftp://ftp.openldap.org/incoming/sean-burford-structural-error-080628.patch -- Thanks, Sean Burford

1 0

Re: (ITS#5582) Default OpenSSL certs are only used when TLS_CACERT(DIR)
by h.b.furuseth＠usit.uio.no 27 Jun '08

27 Jun '08

Howard Chu writes: > Sounds like this works as designed. The docs tell you that > either CACERT or CACERTDIR must be explicitly configured. Maybe, but in that case the bug is that configuring them to an irrelevant certificate works as a "use the OpenSSL defaults" flag. Which is weird at best. And broke our testing: We thought we checked that certain of our users and clients had updated to use our new cert, but actually we just checked that the OpenSSL installations on the test hosts had the CyberTrust root cert. Which got really confusing when we later tried to get some test clients without the new cert to fail. However if we turn this off (remove SSL_CTX_set_default_verify_paths()), we'll likely break existing installations that (intentionally or not) make use of this feature. (Like some of the clients we supposedly tested:-) Thus it seemed best to always load them. Though OTOH I suppose it's not such a good idea to trust a bunch of certs without being asked to do so. Yet if you can't trust your OpenSSL maintainer... Could add a keyword to turn on (or off) loading of defaults, but I do think it should be independent of whether TLS_CACERT(DIR) have been set. -- Hallvard

1 0

Re: (ITS#5582) Default OpenSSL certs are only used when TLS_CACERT(DIR)
by hyc＠symas.com 27 Jun '08

27 Jun '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, 2.3, 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080627.diff > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > OpenLDAP only uses the default certificates installed with OpenSSL if > TLS_CACERT or TLS_CACERTDIR is set. Or presumably > TLSCACertificate<File/Dir> in servers, but the libldap/tls.c code for > servers seem to require a certificate chain from that directory anyway. > Sounds like this works as designed. The docs tell you that either CACERT or CACERTDIR must be explicitly configured. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5582) Default OpenSSL certs are only used when TLS_CACERT(DIR)
by h.b.furuseth＠usit.uio.no 27 Jun '08

27 Jun '08

Full_Name: Hallvard B Furuseth Version: HEAD, 2.3, 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080627.diff Submission from: (NULL) (129.240.6.233) Submitted by: hallvard OpenLDAP only uses the default certificates installed with OpenSSL if TLS_CACERT or TLS_CACERTDIR is set. Or presumably TLSCACertificate<File/Dir> in servers, but the libldap/tls.c code for servers seem to require a certificate chain from that directory anyway. To reproduce: $ export LDAPCONF=/dev/null $ ldapwhoami -xZZh ldap.uio.no certificate verify failed $ export LDAPTLS_CACERT="*any* certificate.pem file" $ ldapwhoami -xZZh ldap.uio.no anonymous Or if it still fails, find where OpenSSL wants its default certs: strace ldapwhoami -xZZh ldap.uio.no 2>&1 | grep ssl and temporarily append the root cert which signed our server cert from https://secure.globalsign.net/cacert/CT_Root_CA.pem Then try again. Something like /usr/local/ssl/cert.pem. $ ldapwhoami -xZZh ldap.uio.no anonymous $ unset LDAPTLS_CACERT; ldapwhoami -xZZh ldap.uio.no certificate verify failed The relevant code is in libldap/tls.c:ldap_int_tls_init_ctx(). I enclose a tentative patch which fixes the above problem, but I'm not sure it's the right one for servers and GnuTLS. The GnuTLS branch does not require a server TLSCACertificateFile, but the OpenSSL code does. I don't know if GnuTLS has a default which is used instead, nor if OpenSSL can have that.

1 0

← Newer
1
2
3
4
5
6
7
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2008