- openldap-bugs - openldap.org

ITS#5581 reopened
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Should be re-fixed now in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5649) overlay_register_control doesn't work
by hyc＠OpenLDAP.org 09 Aug '08

09 Aug '08

Full_Name: Howard Chu Version: 2.3/2.4/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc For non-global overlays, overlay_register_control sets the control flags in the temporary BackendDB structure, which is discarded shortly thereafter. It needs to set the flags in the real BackendDB structure.

1 0

Re: (ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by hyc＠symas.com 08 Aug '08

08 Aug '08

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.11 > OS: openSUSE-11.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.237.56) > > > Hello, > man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and > Every account that should be subject to password policy control should have > pwdPolicySubentry... As usual, it's important that you read every word in the manpage and not skip over anything. The manpage says: >> Every account that should be subject to password policy control should have a pwdPolicySubentry attribute containing the DN of a valid pwdPolicy entry, or they can simply use the configured default. << This means the pwdPolicy entry is some other entry, not that user entries must have the pwdPolicy class. Yes, the overlay depends on the pwdPolicy class because entries of pwdPolicy class must be used to store the policy definitions. It doesn't say that user entries must have pwdPolicy class and it would be stupid to store the policy definitions in the user entries. And it would be pointless to require a pwdPolicySubentry attribute to point to the relevant policy if the policy was simply stored in the user entry. Use your brain. This ITS will be closed. > But ppolicy is controlling every enty, even those without attribute pwdPolicy > and attribute pwdPolicySubentry. > I have created a test entry, which is not subject to password policy but got > locked out after 3 binds with wrong password. > > dn: cn=pw tester,o=avci,c=de > cn: pw tester > createTimestamp: 20080808132851Z > creatorsName: cn=admin,o=avci,c=de > description: Password Tester > entryCSN: 20080808132851.203028Z#000000#000#000000 > entryDN: cn=pw tester,o=avci,c=de > entryUUID: af06a7e2-f999-102c-8d8e-df96a2a401d4 > hasSubordinates: FALSE > modifiersName: cn=admin,o=avci,c=de > modifyTimestamp: 20080808132851Z > objectClass: person > pwdAccountLockedTime: 20080808133126Z > pwdChangedTime: 20080808132851Z > pwdFailureTime: 20080808133058Z > pwdFailureTime: 20080808133109Z > pwdFailureTime: 20080808133126Z > sn: tester > structuralObjectClass: person > subschemaSubentry: cn=Subschema > userPassword: tested > > -Dieter > > > > > -- -- 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#5648) ppolicy controls entries without objectclass pwdPolicy
by dieter＠dkluenter.de 08 Aug '08

08 Aug '08

Michael Ströder <michael(a)stroeder.com> writes: > dieter(a)dkluenter.de wrote: >> man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and >> Every account that should be subject to password policy control should have >> pwdPolicySubentry... >> But ppolicy is controlling every enty, even those without attribute pwdPolicy >> and attribute pwdPolicySubentry. >> I have created a test entry, which is not subject to password policy but got >> locked out after 3 binds with wrong password. > > Do you have 'ppolicy_default' set in slapd.conf? > What happens if you remove that? Yes, I do have ppolicy_default "cn=user,cn=policies,o=avci,c=de" but this should only be applicable if the entry belongs to objectclass pwdPolicy but not without objectclass pwdPolicy declaration. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

1 0

Re: (ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by michael＠stroeder.com 08 Aug '08

08 Aug '08

dieter(a)dkluenter.de wrote: > man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and > Every account that should be subject to password policy control should have > pwdPolicySubentry... > But ppolicy is controlling every enty, even those without attribute pwdPolicy > and attribute pwdPolicySubentry. > I have created a test entry, which is not subject to password policy but got > locked out after 3 binds with wrong password. Do you have 'ppolicy_default' set in slapd.conf? What happens if you remove that? Ciao, Michael.

1 0

(ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by dieter＠dkluenter.de 08 Aug '08

08 Aug '08

Full_Name: Dieter Kluenter Version: 2.4.11 OS: openSUSE-11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.237.56) Hello, man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and Every account that should be subject to password policy control should have pwdPolicySubentry... But ppolicy is controlling every enty, even those without attribute pwdPolicy and attribute pwdPolicySubentry. I have created a test entry, which is not subject to password policy but got locked out after 3 binds with wrong password. dn: cn=pw tester,o=avci,c=de cn: pw tester createTimestamp: 20080808132851Z creatorsName: cn=admin,o=avci,c=de description: Password Tester entryCSN: 20080808132851.203028Z#000000#000#000000 entryDN: cn=pw tester,o=avci,c=de entryUUID: af06a7e2-f999-102c-8d8e-df96a2a401d4 hasSubordinates: FALSE modifiersName: cn=admin,o=avci,c=de modifyTimestamp: 20080808132851Z objectClass: person pwdAccountLockedTime: 20080808133126Z pwdChangedTime: 20080808132851Z pwdFailureTime: 20080808133058Z pwdFailureTime: 20080808133109Z pwdFailureTime: 20080808133126Z sn: tester structuralObjectClass: person subschemaSubentry: cn=Subschema userPassword: tested -Dieter

1 0

(ITS#5647) problem with ldap backend / rwm overlay
by brett.maxfield＠gmail.com 07 Aug '08

07 Aug '08

Full_Name: Brett Maxfield Version: slapd 2.4.11 (Jul 29 2008 19:56:20) OS: SunOS qgdmzmlr01 5.10 Generic_127111-11 sun4v sparc SUNW,Sun-Fire-T200 URL: Submission from: (NULL) (203.18.108.168) I am trying to setup a ldap backend which is a filtered view of another larger parent directory, with respect to exposing fewer object classes and attributes. The intent is to present a simpler view of the larger directory, and the config below works, except for when i uncomment the line containing "rwm-map attribute *", to hide the attributes i do not want visible, but after that it stops returning any entries at all for any query. So may be there is some important openldap attribute i am nuking ? The below config works, until the "rwm-map attribute *" line is uncommented, the ldap backend stops returning any entries. Pierangelo Masarati on the list stated : <quote> Yes, I fear that's hiding the objectClass attribute, which is required for internal operations. On the other hand, you can't simply tell back-ldap to preserve that attribute, because mapping objectClass is not allowed. I suggest you file an ITS so that this problem can be fixed. </quote> I have tried mapping the "rwm-map attribute objectClass *", and as Perangelo states, the error is "objectclass attribute cannot be mapped". If this is true, then the usability of rwm-map attribute is extremely compromised, and probably unusable? The structure of the parent directory is : c=AU o=My Org 1 ou=My Unit 1 o=My Org 2 ou=My Unit 2 Config is : database ldap suffix "c=AU" uri "ldap://<parent ip>:<parent port>/" overlay rwm lastmod off # attribute maps (ok except for final "rwm-map attribute *" map) rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * # does not like this, it stops any entries being returned #rwm-map attribute * # objectclass maps (ok) rwm-map objectclass top * rwm-map objectclass country * rwm-map objectclass organization * rwm-map objectclass organizationalRole * rwm-map objectclass organizationalPerson * rwm-map objectclass organizationalUnit * rwm-map objectclass *

1 0

Re: (ITS#5646) Unable to make the openldap-2.4.11 in fedora9
by hyc＠symas.com 07 Aug '08

07 Aug '08

snkg24(a)gmail.com wrote: > Full_Name: Nar > Version: openldap-2.4.11 > OS: Fedora 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.93.52.62) > > > Hi all, > > I am unable to install the openldap using configure. The following error > appearing after inputting the command "make". > > Please provide the solution. This is a dup of ITS#5464, a bug in glibc. https://www.openldap.org/its/index.cgi/Build?id=5464 This ITS will be closed, you can send further followups to ITS#5464. -- -- 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#5646) Unable to make the openldap-2.4.11 in fedora9
by snkg24＠gmail.com 07 Aug '08

07 Aug '08

Full_Name: Nar Version: openldap-2.4.11 OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.93.52.62) Hi all, I am unable to install the openldap using configure. The following error appearing after inputting the command "make". Please provide the solution. ----------- [root@eltserv openldap-2.4.11]# make Making all in /root/Download/openldap-2.4.11 Entering subdirectory include make[1]: Entering directory `/root/Download/openldap-2.4.11/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/root/Download/openldap-2.4.11/include' Entering subdirectory libraries make[1]: Entering directory `/root/Download/openldap-2.4.11/libraries' Making all in /root/Download/openldap-2.4.11/libraries Entering subdirectory liblutil make[2]: Entering directory `/root/Download/openldap-2.4.11/libraries/liblutil' rm -f version.c ../../build/mkversion -v "2.4.11" liblutil.a > version.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o utils.o utils.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o fetch.o fetch.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o getpeereid.o getpeereid.c getpeereid.c: In function lutil_getpeereid: getpeereid.c:65: error: storage size of peercred isnt known make[2]: *** [getpeereid.o] Error 1 make[2]: Leaving directory `/root/Download/openldap-2.4.11/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/root/Download/openldap-2.4.11/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by hyc＠symas.com 06 Aug '08

06 Aug '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) >> This is now fixed in HEAD. > > Slapd should to refuse to start with a bogus OID like that. > OIDs start with components<0-1>.<0-39> or 2.<any>. > > The LDAP standard doesn't seem to mention this, but RFC 4517 does defer > to X.680 (the ASN.1 spec), which since 1998 has deferred to X.660 - > which I don't have:-( Anyway, my reference is John Larmouth's _ASN.1 > Complete_. And it can be inferred from the BER encoding of the OBJECT > IDENTIFIER type. > Feel free to patch it. The fix I committed was simply to the double-free for any attributeType that inherits from objectClass... -- -- 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#5644) make test000 core dumps
by michael＠stroeder.com 06 Aug '08

06 Aug '08

Ralf Haferkamp wrote: > On Dienstag, 5. August 2008, michael(a)stroeder.com wrote: >> [..] >> slapd starting >> daemon: listen(ldap://localhost:9011/, 5) failed errno=3D98 (Address >> alre= ady in use) >> lt-slapd shutdown: initiated >> =3D=3D=3D=3D> bdb_cache_release_all >> lt-slapd destroy: freeing system resources. >> slapd stopped. >> >> --------------000504090501070603080100-- > This might just be another incarnation of ITS#5251 (duplicate results > from getaddrinfo()). Indeed removing 'localhost' from /etc/hosts in the line starting with '::1' solved this. On my former openSUSE 10.3 system I had disabled IPv6 completely. Hmm... So you can mark ITS#5644 as duplicate of ITS#5251. Ciao, Michael.

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by h.b.furuseth＠usit.uio.no 06 Aug '08

06 Aug '08

hyc(a)symas.com writes: >> attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) > > This is now fixed in HEAD. Slapd should to refuse to start with a bogus OID like that. OIDs start with components <0-1>.<0-39> or 2.<any>. The LDAP standard doesn't seem to mention this, but RFC 4517 does defer to X.680 (the ASN.1 spec), which since 1998 has deferred to X.660 - which I don't have:-( Anyway, my reference is John Larmouth's _ASN.1 Complete_. And it can be inferred from the BER encoding of the OBJECT IDENTIFIER type. -- Hallvard

1 0

Re: (ITS#5644) make test000 core dumps
by rhafer＠suse.de 06 Aug '08

06 Aug '08

On Dienstag, 5. August 2008, michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------000504090501070603080100 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > Pierangelo Masarati wrote: > > ----- "Michael Ströder" <michael(a)stroeder.com> wrote: > >> Pierangelo Masarati wrote: > >>> Are you sure you're loading the sasl mechs you've compiled for? > >> > >> That's a typical issue with SASL (see SASL_PATH, in case). > >> > >>>> #2 0x405df014 in ?? () from /usr/lib/libldap-2.4.so.2 > >> > >> Hmm, it seems the problem is rather that the LDAP client libs from > >> the > >> > >> RPM package installed by openSUSE are loaded instead the ones from > >> the > >> > >> build directory. That's bad. Any way around this when running > >> 'make test'? > > > > LD_LIBRARY_PATH to your just built libs? > > Hmm, I don't have a clue what's going on. I tried with my RE24 source > tree from which I've successfully built a couple of days ago. I've > removed openSUSE packages for OpenLDAP client libs and > cyrus-sasl-ldap-auxprop. Still no success. It does not core dump > anymore but slapd does not start (see below). > > Ciao, Michael. > > -------------------------------- snip > --------------------------------- > > >>>>> Starting test000-rootdse ... > > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: line 66: kill: (21057) - No such process > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > >>>>> Test failed > >>>>> ./scripts/test000-rootdse failed (exit 255) > [..] > make: *** [test] Error 2 > -------------------------------- snip > --------------------------------- [..] > slapd starting > daemon: listen(ldap://localhost:9011/, 5) failed errno=3D98 (Address > alre= ady in use) > lt-slapd shutdown: initiated > =3D=3D=3D=3D> bdb_cache_release_all > lt-slapd destroy: freeing system resources. > slapd stopped. > > --------------000504090501070603080100-- This might just be another incarnation of ITS#5251 (duplicate results from getaddrinfo()). -- Ralf

1 0

ITS#5581 reopened
by ando＠sys-net.it 06 Aug '08

06 Aug '08

I have re-opened this bug. I have a fix, will commit ASAP. I confirm the bug only seems to affect malformed filters in the URI. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5581) slapd: search.c:970: oc_filter: Assertion `f != ((void *)0)' failed.
by ando＠sys-net.it 06 Aug '08

06 Aug '08

----- stef(a)memberwebs.com wrote: > I get this problem with 2.4.11 (but not with 2.4.10). My slapo-unique > configuration is as follows: > > unique_uri ldap:///?cn?sub > unique_uri ldap:///?uid,login?sub?(!(disabled=TRUE)) > > The filter seems valid to me, but please correct me if I'm wrong. Does "disabled" exist? I mean: is it defined __before__ this line in your slapd.conf? Does TRUE comply with its syntax? I've checked the fix to this bug, and it seems to mischeck the validity of the filter, so if what you specify in the "filter" field of the URI is not a valid filter, the string "(?=error)" shows up instead of the normalization of your filter, causing subsequent harm to filter evaluation. This does not occur if the filter is valid, so there must be also an error on your side (I'm fixing the test, in the meanwhile, so that the error is notified while parsing the configuration). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by dbb＠st-andrews.ac.uk 06 Aug '08

06 Aug '08

Thanks. Howard Chu wrote: > dbb(a)st-andrews.ac.uk wrote: >> Just an update, still present in 2.4.11, backtrace below. Still can't >> work out why it's happening, >> it's something in the way that sendmail uses ldap and not the actual >> queries that cause the crash. >> >> I can replay the connections and searches to the server, and I've used >> Suns ldap load testing software >> to load up the server way over what we ever see and I can't replicate >> the SIGABRT or crash it in any >> other way. >> >> Any help appreciated. > > In frame 5 > print *index > print connections[*index] /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-6-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@10 a l@10 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() (dbx) thread t@2 t@2 (l@2) stopped in __lwp_kill at 0xfe2c0f90 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217978957), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) print *index *index = 33 (dbx) print connections[*index] connections[*index] = { c_struct_state = 2 c_conn_state = 1 c_conn_idx = 33 c_sd = 33 c_close_reason = 0x1a11bc "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x45fbd0 c_starttime = 1217978957 c_activitytime = 1217978957 c_connid = 436161U c_peer_domain = { bv_len = 7U bv_val = 0x48fda0 "unknown" } c_peer_name = { bv_len = 22U bv_val = 0x4b34b8 "IP=138.251.30.31:34746" } c_listener = 0x23ea28 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x2c2664 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x2c266c } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x4252d8 c_sasl_sockctx = (nil) c_sasl_extra = 0x43a298 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 0 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 0 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x67ac8 = &slap_send_ldap_result() c_send_search_entry = 0x68c40 = &slap_send_search_entry() c_send_search_reference = 0x6b320 = &slap_send_search_reference() c_send_ldap_extended = 0x685e8 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x68968 = &slap_send_ldap_intermediate() } (dbx) A second example in case useful /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-1300-4-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217851229), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() (dbx) print *index *index = 21 (dbx) print connections[*index] connections[*index] = { c_struct_state = 2 c_conn_state = 1 c_conn_idx = 21 c_sd = 21 c_close_reason = 0x1a11bc "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x435300 c_starttime = 1217851229 c_activitytime = 1217851229 c_connid = 6825U c_peer_domain = { bv_len = 7U bv_val = 0x419470 "unknown" } c_peer_name = { bv_len = 22U bv_val = 0x413908 "IP=138.251.30.32:40070" } c_listener = 0x23ea28 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x2c16a4 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x2c16ac } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x426680 c_sasl_sockctx = (nil) c_sasl_extra = 0x4346a8 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 0 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 0 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x67ac8 = &slap_send_ldap_result() c_send_search_entry = 0x68c40 = &slap_send_search_entry() c_send_search_reference = 0x6b320 = &slap_send_search_reference() c_send_ldap_extended = 0x685e8 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x68968 = &slap_send_ldap_intermediate() } -- The University of St Andrews is a charity registered in Scotland : No SC013532

1 0

Re: (ITS#5641) Segmentation fault - slaptest and slapd
by ando＠sys-net.it 06 Aug '08

06 Aug '08

----- hyc(a)symas.com wrote: > hfranzke(a)tee.toshiba.de wrote: > > Full_Name: Helmut Franzke > > Version: 2.4.11 / 2.4.9 > > OS: Ubuntu server 8.04.1 / Centos 4.6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (192.109.150.105) > > > > > > I could get slaptest/slapd to produce a segmentation fault by using > the unique > > overlay and a unique_uri with a base dn. This behaviour depends on > the position > > of the overlay/unique_uri in slapd.conf and doesn't appear if you > don't use a > > base dn regardless of the position. (I know an overlay should be > defined after > > the other configuration settings have been set. I encountered this > bug when I > > put it in the first part by mistake, see below) > > We should of course fix the SEGV, but it is already documented that > overlays > must be configured after their corresponding databases. As such, this > is not a > high priority. slapo-unique uses be_nsuffix without testing it, and it's obviously NULL until "suffix" is defined. The fix is trivial, but I can't commit right now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by hyc＠symas.com 05 Aug '08

05 Aug '08

dbb(a)st-andrews.ac.uk wrote: > Just an update, still present in 2.4.11, backtrace below. Still can't > work out why it's happening, > it's something in the way that sendmail uses ldap and not the actual > queries that cause the crash. > > I can replay the connections and searches to the server, and I've used > Suns ldap load testing software > to load up the server way over what we ever see and I can't replicate > the SIGABRT or crash it in any > other way. > > Any help appreciated. In frame 5 print *index print connections[*index] -- -- 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#5641) Segmentation fault - slaptest and slapd
by hyc＠symas.com 05 Aug '08

05 Aug '08

hfranzke(a)tee.toshiba.de wrote: > Full_Name: Helmut Franzke > Version: 2.4.11 / 2.4.9 > OS: Ubuntu server 8.04.1 / Centos 4.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.109.150.105) > > > I could get slaptest/slapd to produce a segmentation fault by using the unique > overlay and a unique_uri with a base dn. This behaviour depends on the position > of the overlay/unique_uri in slapd.conf and doesn't appear if you don't use a > base dn regardless of the position. (I know an overlay should be defined after > the other configuration settings have been set. I encountered this bug when I > put it in the first part by mistake, see below) We should of course fix the SEGV, but it is already documented that overlays must be configured after their corresponding databases. As such, this is not a high priority. -- -- 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#5642) Double free on exit, when specific attributetype is defined
by hyc＠symas.com 05 Aug '08

05 Aug '08

stef(a)memberwebs.com wrote: > Full_Name: Stef Walter > Version: 2.4.11 > OS: FreeBSD 6.3-RELEASE-p2 > URL: > Submission from: (NULL) (38.99.5.20) > > > When the following line is present in the schema (or slapd.conf), then upon exit > any slap* process aborts due to a double free of memory: > > attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) > > > The OID is obviously fictional. This can be triggered reliably by running: > > # slaptest > This is now fixed in HEAD. -- -- 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#5639) Digital (PGP-)signature for downloadable sources
by Kurt＠OpenLDAP.org 05 Aug '08

05 Aug '08

On Aug 4, 2008, at 9:56 PM, h.b.furuseth(a)usit.uio.no wrote: > Kurt(a)OpenLDAP.org writes: >> On Aug 4, 2008, at 2:06 PM, h.b.furuseth(a)usit.uio.no wrote: >>> Kurt(a)OpenLDAP.org writes: >>>> I note as well that properly deploying release signing requires >>>> more than script modification. For instance, one does need to >>>> consider that the host to sign the releases might itself been >>>> taken over and the implications of such a takeover. >>> >>> For that part, signatures in the 'https:' site would help. >> >> I think you need to re-think that assertion. > > Er, yes, I was thinking of the "outside" equivalent, hacking DNS and > "taking over" that way. Those mounting such attacks are more likely to take over google.com than openldap.org. > I have the impression that's the most common way to "take over" a > site, but I may be wrong. I would say it's a more commonly talked about "take over" approach at present. Though I don't know if its more common that other major site "take over" approaches. But "take over" of small sites, such are openldap.org, are different because the goal is different. Folks "take over" major sites (generally in an isolated way, such as via a particular ISP) because there is a reasonable chance that users will access the taken over site. These take overs often are attempts to install malware on user systems (be careful, that google search button might not be a true google search button). Take over of small sites is commonly done to deface the site, to gain notoriety or to grind an axe or something. So, I'm not particularly worried about former, but am worried about the latter. But you and others brought up https:// in the context of a PGP signing discussion. This is, I think, confused. -- Kurt

1 0

Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
by Kurt＠OpenLDAP.org 05 Aug '08

05 Aug '08

I figure that an attacker can convince most downloaders who might verify a PGP signature that the project no longer signs releases, making the project's use of PGP signatures moot. While it can be argued that there might be some downloaders who want to establish rigid signature verification procedures and follow them, I simply haven't heard anyone claim to be such a downloader. And even if there where a few that might now claim this, I think the amount of work involved (both initially and on a per release basis) is worth the time spent. I would argue time is better spent on improvements that are benefit most downloaders, such as a more comprehensive web/ftp change detection/notice system. -- Kurt

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by hyc＠symas.com 05 Aug '08

05 Aug '08

stef(a)memberwebs.com wrote: > Full_Name: Stef Walter > Version: 2.4.11 > OS: FreeBSD 6.3-RELEASE-p2 > URL: > Submission from: (NULL) (38.99.5.20) > > > When the following line is present in the schema (or slapd.conf), then upon exit > any slap* process aborts due to a double free of memory: > > attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) > > > The OID is obviously fictional. This can be triggered reliably by running: > > # slaptest This also occurs in 2.3, and is specific to objectClass and a few other built in attributes with custom matching rules. -- -- 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#5645) <suffix> invalid DN 21 (Invalid syntax)
by support＠msm-projects.net 05 Aug '08

05 Aug '08

Full_Name: MSM-Projects Support Version: 2.4.11 OS: Debian Linux (2.6.18-6-xen-amd64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.9.60.153) We installed a ldap server version 2.4.11. With default slapd.conf the server is starting. Changing the default-suffix to a version we need (building a replica with an existing host), we get error: line 54 (suffix "o=my-domain, c=com") >>> dnPrettyNormal: <o=my-domain, c=com> => ldap_bv2dn(o=my-domain, c=com,0) <= ldap_bv2dn(o=my-domain, c=com)=0 ldap_err2string /usr/local/openldap/etc/openldap/slapd.conf: line 54: <suffix> invalid DN 21 (Invalid syntax)

1 0

Re: (ITS#5581) slapd: search.c:970: oc_filter: Assertion `f != ((void *)0)' failed.
by stef＠memberwebs.com 05 Aug '08

05 Aug '08

I get this problem with 2.4.11 (but not with 2.4.10). My slapo-unique configuration is as follows: unique_uri ldap:///?cn?sub unique_uri ldap:///?uid,login?sub?(!(disabled=TRUE)) The filter seems valid to me, but please correct me if I'm wrong.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs