openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5583) slapadd core dumps
by dieter＠dkluenter.de 29 Jun '08

29 Jun '08

Full_Name: Dieter Kluenter Version: 2.4.10 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.217.87) Hello, processor: amd64 my configure flags: export CFLAGS="-g -march=athlon64" PREFIX="/opt/openldap" DATABASE="bdb" make distclean ; ./configure \ --prefix=${PREFIX} \ --enable-dynamic \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-ldap=mod \ --enable-monitor=yes \ --enable-meta=mod \ --enable-perl=mod \ --enable-relay=mod \ --enable-monitor=yes \ --enable-sql=mod \ --enable-overlays=mod make depend && make && cd tests ; running slapadd with following options ./slapd -T add -d-1 -qwv -f /opt/openldap/etc/openldap/slapd.conf -F /opt/openldap/etc/openldap/slapd.d -l /tmp/hdk-init.ldif slapadd startup: initiated. backend_startup_one: starting "o=avci,c=de" hdb_db_open: "o=avci,c=de" hdb_db_open: database "o=avci,c=de": dbenv_open(/tmp/ldap). slapd: ad.c:164: slap_bv2ad: Assertion `*ad == ((void *)0)' failed. Abgebrochen (core dumped) output of gdb (gdb) file /work/openldap/2.4.10/servers/slapd/.libs/slapd Reading symbols from /work/openldap/2.4.10/servers/slapd/.libs/slapd..done (gdb) core-file core warning: Can't read pathname for load map: Input/output error. Reading symbols from /opt/openldap/lib/libldap_r-2.4.so.2...done. Loaded symbols for /opt/openldap/lib/libldap_r-2.4.so.2 Reading symbols from /opt/openldap/lib/liblber-2.4.so.2...done. Loaded symbols for /opt/openldap/lib/liblber-2.4.so.2 Reading symbols from /usr/lib64/libltdl.so.3...done. Loaded symbols for /usr/lib64/libltdl.so.3 Reading symbols from /usr/lib64/libdb-4.5.so...done. Loaded symbols for /usr/lib64/libdb-4.5.so Reading symbols from /usr/lib64/libodbc.so.1...done. Loaded symbols for /usr/lib64/libodbc.so.1 Reading symbols from /lib64/libpthread.so.0...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /usr/lib64/libssl.so.0.9.8...done. Loaded symbols for /usr/lib64/libssl.so.0.9.8 Reading symbols from /usr/lib64/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib64/libcrypto.so.0.9.8 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libz.so.1...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /usr/lib64/sasl2/liblogin.so...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /usr/lib64/sasl2/libanonymous.so...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so Reading symbols from /usr/lib64/sasl2/libdigestmd5.so...done. Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so Reading symbols from /usr/lib64/sasl2/libcrammd5.so...done. Loaded symbols for /usr/lib64/sasl2/libcrammd5.so Reading symbols from /usr/lib64/sasl2/libsasldb.so...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /usr/lib64/sasl2/libplain.so...done. Loaded symbols for /usr/lib64/sasl2/libplain.so Reading symbols from /opt/openldap/libexec/openldap/dynlist-2.4.so.2...done. Loaded symbols for /opt/openldap/libexec/openldap/dynlist-2.4.so.2 Reading symbols from /opt/openldap/libexec/openldap/accesslog-2.4.so.2...done. Loaded symbols for /opt/openldap/libexec/openldap/accesslog-2.4.so.2 Reading symbols from /opt/openldap/libexec/openldap/ppolicy-2.4.so.2...done. Loaded symbols for /opt/openldap/libexec/openldap/ppolicy-2.4.so.2 Reading symbols from /opt/openldap/libexec/openldap/syncprov-2.4.so.2...done. Loaded symbols for /opt/openldap/libexec/openldap/syncprov-2.4.so.2 Core was generated by `./slapd -Tadd -d-1 -qwv -f /opt/openldap/etc/openldap/slapd.conf -F /opt/openld' Program terminated with signal 6, Aborted. [New process 16951] #0 0x00007f39e0ea95c5 in raise () from /lib64/libc.so.6 (gdb) quit -Dieter

1 0

Re: (ITS#5579) Interaction of ppolicy attributes
by andrew.findlay＠skills-1st.co.uk 29 Jun '08

29 Jun '08

On Sat, Jun 28, 2008 at 07:21:44PM -0700, Howard Chu wrote: > >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. Indeed, though draft-behera-ldap-password-policy-xx.txt is a bit unclear on the subject of that attribute: 5.3.3 pwdAccountLockedTime This attribute holds the time that the user's account was locked. A locked account means that the password may no longer be used to authenticate. A 000001010000Z value means that the account has been locked permanently, and that only a password administrator can unlock the account. One reading of that clause is that *setting* pwdAccountLockedTime to 000001010000Z is the way to lock an account by administrative action. There does not appear to be anything in the I-D that would cause the server to set that value itself. The current implementation does allow admins to set the value, which appears to be the only way to lock/unlock an account without changing the password. I would certainly prefer to have separate attributes for 'admin lock' and 'auto lock'. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

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

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