- openldap-bugs - openldap.org

(ITS#6463) dnssrv_back_referrals: ldaps not handled, search base gone
by jochen＠keutel.de 26 Jan '10

26 Jan '10

Full_Name: Jochen Keutel Version: 2.4.21 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.206.14) dnssrv_back_referrals() always returns ldap URLs - even when the original request was a ldaps query. Additionally only protocol and hostname are put into the URL - the search base doesn't appear any more. Problematic code: url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] ); url.bv_val = ch_malloc( url.bv_len + 1 ); strcpy( url.bv_val, "ldap://" ); strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] ); I'm not sure whether you want me to deliver a complete patch or not ... Thanks to my colleague Manuel Gaupp for detecting this problem. Best regards, Jochen.

1 0

(ITS#6462) DNS SRV records: ldaps ???
by jochen＠keutel.de 26 Jan '10

26 Jan '10

Full_Name: Jochen Keutel Version: 2.4.21 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.206.14) The code for detecting LDAP servers via DNS SRV records seems to handle only ldap URLs - not ldaps URLs. Esp.: If you access an OpenLDAP server with ldaps://host1/..., then the DNS SRV code returns a URL like ldap://host2/... . So the LDAP server chains the original ldaps request as a LDAP query without TLS. This gets problematic when the (company / project) requirements clearly state that only ldaps has to be used ... The problematic code seems to be in libraries/libldap/dnssrv.c, function ldap_domain2hostlist(): request = LDAP_MALLOC(strlen(domain) + sizeof("_ldap._tcp.")); ... sprintf(request, "_ldap._tcp.%s", domain); So always "_ldap._tcp" is used (hard coded) - not "ldaps._tcp" in case of ldaps in the original query. I'd suggest to introduce a third parameter to that function: int ldap_domain2hostlist( LDAP_CONST char *protocol, LDAP_CONST char *domain, char **list ) protocol is either "ldap" oder "ldaps". The code calling this function (slapd/back-dnssrv/search.c and referral.c) has to be adjusted as well. I'm not sure whether you want me to deliver a complete patch or not ... Thanks to my colleague Manuel Gaupp for detecting this problem. Best regards, Jochen.

1 0

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by masarati＠aero.polimi.it 25 Jan '10

25 Jan '10

Guillaume.Rousse(a)inria.fr wrote: > Le 18/01/2010 17:13, masarati(a)aero.polimi.it a écrit : >> Could not reproduce. Apparently, it's something else that's creating >> hassle. Please provide a stack backtrace. > > Actually, it's an assertion failure un entry.c: > slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' > failed. > Abandon > > Here the backtrace, but compilation optimisation may hinder its usability: Well, at least it shows where the failure is. However, since I can't reproduce it, I'll need your (sanitized) slapd.conf, a LDIF to load and the operation that causes the failure. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 25 Jan '10

25 Jan '10

Howard Chu wrote: > masarati(a)aero.polimi.it wrote: >>> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >>>> Funny enough, the same thing is dealt with correctly in certificate >>>> validation/normalization in slapd/schema_init.c >>> That was a result of ITS#5070 (which you filed). >> right :) >> >>> Maybe there is an >>> opportunity for refactoring, but I wouldn't be a good judge of that. >> I don't quite bother about refactoring to minimize code duplication. >> Rather, I think the libldap function x509_cert_get_dn() should first >> validate the certificate, much like slapd's certificateValidate() does. > > Since the cert was obtained thru a TLS handshake, we assume it has already > been validated by the TLS library. Further validation is not needed. What I mean is that the TLS library may handle certificates that our function does not like (as in this case). Slapd's code, while skipping fields, checks their tags. We should do the same here, IMHO. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by hyc＠symas.com 24 Jan '10

24 Jan '10

masarati(a)aero.polimi.it wrote: >> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >>> Funny enough, the same thing is dealt with correctly in certificate >>> validation/normalization in slapd/schema_init.c >> >> That was a result of ITS#5070 (which you filed). > > right :) > >> Maybe there is an >> opportunity for refactoring, but I wouldn't be a good judge of that. > > I don't quite bother about refactoring to minimize code duplication. > Rather, I think the libldap function x509_cert_get_dn() should first > validate the certificate, much like slapd's certificateValidate() does. Since the cert was obtained thru a TLS handshake, we assume it has already been validated by the TLS library. Further validation is not needed. -- -- 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#6461) back-sql quote characters in query
by tolich.arz＠gmail.com 24 Jan '10

24 Jan '10

Full_Name: Anatoly Version: 2.4.19 OS: GNU/Linux URL: Submission from: (NULL) (89.169.85.181) I'm using openldap 2.4.19 with sql backend. I have a troubles with queries that contains single-quote ( ' ) character. For example, if I searching for (cn=Zool'man): <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') Constructed query: SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') id: '2' backsql_oc_get_candidates(): error executing query Return code: -1 nativeErrCode=7 SQLengineState=S1000 msg="[unixODBC]ERROR: syntax error at or near "MAN" at character 271; In this case query should be like varchar_ci(phpbb_users.username)='ZOOL\'MAN' instead of 'ZOOL'MAN' Additionally, I fear this opens a possibility of sql injection, depending on RDBMS.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 24 Jan '10

24 Jan '10

* masarati(a)aero.polimi.it [2010-01-24 19:14:02 +0100]: > I'm applying the fix, please test. I'm in production with the fix (on 2.4.11; I don't have the time to deploy HEAD right now). syncrepl (which is what I'm using SASL EXTERNAL for) now works again. As for the need to validate the certificate: shouldn't this have been taken care of during the preceding TLS handshake?

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 24 Jan '10

24 Jan '10

> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >> Funny enough, the same thing is dealt with correctly in certificate >> validation/normalization in slapd/schema_init.c > > That was a result of ITS#5070 (which you filed). right :) > Maybe there is an > opportunity for refactoring, but I wouldn't be a good judge of that. I don't quite bother about refactoring to minimize code duplication. Rather, I think the libldap function x509_cert_get_dn() should first validate the certificate, much like slapd's certificateValidate() does. I'm applying the fix, please test. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 24 Jan '10

24 Jan '10

* masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: > Funny enough, the same thing is dealt with correctly in certificate > validation/normalization in slapd/schema_init.c That was a result of ITS#5070 (which you filed). Maybe there is an opportunity for refactoring, but I wouldn't be a good judge of that.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 24 Jan '10

24 Jan '10

> Full_Name: Sergio Gelato > Version: 2.4.11 (problem also in HEAD) > OS: Debian GNU/Linux > URL: > Submission from: (NULL) (85.225.123.197) > > > Using (X.509 certificate-based) SASL EXTERNAL authentication fails when > the > serial number of the certificate is longer than 4 octets. > > I have traced the problem to the use, by > libraries/libldap/tls.c:x509_cert_get_dn(), > of ber_get_int() to consume the serial number. This fails when the value > to be > decoded > doesn't fit in a ber_int_t. > > I discovered this bug with Debian's OpenLDAP 2.4.11-1+lenny1 but a look at > the > OpenLDAP CVS indicates that the problem is still present in the current > HEAD > (1.167). > > I've successfully tested the following patch: > ==================================================================================== > RFC5280 §4.1.2.2 says "[c]ertificate users MUST be able to handle > serialNumber > values up to 20 octets". ber_get_int() fails beyond 4 octets. Since we > don't > actually care about the certificate serial number, let's just skip it. > > --- a/libraries/libldap/tls.c > +++ b/libraries/libldap/tls.c > @@ -1673,7 +1673,8 @@ > tag = ber_skip_tag( ber, &len ); /* Context + Constructed (version) */ > if ( tag == 0xa0 ) /* Version is optional */ > tag = ber_get_int( ber, &i ); /* Int: Version */ > - tag = ber_get_int( ber, &i ); /* Int: Serial */ > + tag = ber_skip_tag( ber, &len ); /* *Big* integer: Serial */ > + ber_skip_data( ber, len ); > tag = ber_skip_tag( ber, &len ); /* Sequence: Signature */ > ber_skip_data( ber, len ); > if ( !get_subject ) { Funny enough, the same thing is dealt with correctly in certificate validation/normalization in slapd/schema_init.c p.

1 0

(ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 23 Jan '10

23 Jan '10

Full_Name: Sergio Gelato Version: 2.4.11 (problem also in HEAD) OS: Debian GNU/Linux URL: Submission from: (NULL) (85.225.123.197) Using (X.509 certificate-based) SASL EXTERNAL authentication fails when the serial number of the certificate is longer than 4 octets. I have traced the problem to the use, by libraries/libldap/tls.c:x509_cert_get_dn(), of ber_get_int() to consume the serial number. This fails when the value to be decoded doesn't fit in a ber_int_t. I discovered this bug with Debian's OpenLDAP 2.4.11-1+lenny1 but a look at the OpenLDAP CVS indicates that the problem is still present in the current HEAD (1.167). I've successfully tested the following patch: ==================================================================================== RFC5280 §4.1.2.2 says "[c]ertificate users MUST be able to handle serialNumber values up to 20 octets". ber_get_int() fails beyond 4 octets. Since we don't actually care about the certificate serial number, let's just skip it. --- a/libraries/libldap/tls.c +++ b/libraries/libldap/tls.c @@ -1673,7 +1673,8 @@ tag = ber_skip_tag( ber, &len ); /* Context + Constructed (version) */ if ( tag == 0xa0 ) /* Version is optional */ tag = ber_get_int( ber, &i ); /* Int: Version */ - tag = ber_get_int( ber, &i ); /* Int: Serial */ + tag = ber_skip_tag( ber, &len ); /* *Big* integer: Serial */ + ber_skip_data( ber, len ); tag = ber_skip_tag( ber, &len ); /* Sequence: Signature */ ber_skip_data( ber, len ); if ( !get_subject ) {

1 0

Re: (ITS#6364) refint needs to have rootdn set
by apm＠mutex.dk 22 Jan '10

22 Jan '10

This may be related. I've veryfied that my refint overlay is not working. However I have a rootdn defined for the database, but it is set to cn=config. Could it be that the rootdn has to be in the scope of the database for refint to work? slapd 2.4.20, back-hdb, BerkeleyDB 4.8.24 /Peter

1 0

(ITS#6459) memory leak in syncprov
by rhafer＠suse.de 21 Jan '10

21 Jan '10

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.21.216) When sending SYNC_NEW_COOKIE intermedia results syncprov_qplay() does not free the entry from the syncres structure. A fix is on the way...

1 0

(ITS#6458) syncrepl fails if attribute has no equalty maching rule
by pcernko+openldap＠mpi-sws.org 20 Jan '10

20 Jan '10

Full_Name: Patrick Cernko Version: 2.4.21 OS: Linux URL: http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… Submission from: (NULL) (139.19.3.67) Hi OpenLDAP-Programmers, although some related bug reports were posted in the past years, this issue still seems not to be fixed: OpenLDAP's syncrepl replication fails if it comes to removing one of a multi-value attribes of an object if this attribute does not have a equality matching rule defined in the schema. Modification works on the master server but fails to replicate to the slave(s) leaving them with the dit version just before and not replicating any other changes any more. I compiled a small example how to reproduce the problem with the (maybe "well-known") nisNetgroupTriple attribute from nis.schema as shipped with openldap-2.4.21: - extract the files from http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… into an empty working directory - download the tarball to that working dir and configure similar to the just extracted configure.sh - build and install it to get an install subdir in the working dir - start the master using sh master.sh in the working dir This will create the "master" database in your working dir, slapadd the dit.ldif and start a master slapd with a unix socket /tmp/master. - start the slave using sh slave.sh This will create "slave" database in your working dir and start the slave slapd with a unix socket /tmp/slave which will immediately start syncing from the running master - if you want you can search the 2 servers with install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL resp. install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL - use "python mod.py" to remove one of the nisNetgroupTriple attributes from the netgroup object - you will see a debug message from the slave server like this: bdb_modify_internal: delete nisNetgroupTriple bdb_modify_internal: 18 modify/delete: nisNetgroupTriple: no equality matching rule send_ldap_result: err=18 matched="" text="modify/delete: nisNetgroupTriple: no equality matching rule" null_callback : error code 0x12 slap_graduate_commit_csn: removing 0x29931c0 20100120124712.028626Z#000000#000#000000 syncrepl_entry: rid=001 be_modify cn=netgroup,ou=openldap (18) syncrepl_entry: rid=001 be_modify failed (18) if not, use "python mod.py add" to re-add the removed nisNetgroupTriple and try again. Sometimes, it seems to work (race condition?). - you can also verify the difference with: install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL cn=netgroup install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL cn=netgroup - from now on, the slave will fail to sync any succeeding changes, as it continuously tries to sync the modification above first. :-( Now, obviously having an attribute without equality matching rule is not a good idea in the first place. However, the (official?) nis.schema comes with such an attribute which we must use like this (e.g. we would have to patch the Solaris kernel to change it for the Solaris NFS server). It is possible to modify a nisNetgroup object like this: according to the debugging output, I guess the master removes simply ALL nisNetgroupTriple attributes and adds only the attributes that should remain. When the corresponding syncrepl_entry is handled by the slave, it seems the it in contrast tries to really only remove the 2-be-removed attribute which does not work as it cannot identify the right one due to a missing eq-match operator. I suggest the best way to solve this issue is to try to get syncrepl do exactly the same actions (not resulting changes) as the server does.

1 0

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by Guillaume.Rousse＠inria.fr 20 Jan '10

20 Jan '10

Le 18/01/2010 17:13, masarati(a)aero.polimi.it a écrit : > Could not reproduce. Apparently, it's something else that's creating > hassle. Please provide a stack backtrace. Actually, it's an assertion failure un entry.c: slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed. Abandon Here the backtrace, but compilation optimisation may hinder its usability: #0 0x00007ffff6476955 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 pid = <value optimized out> selftid = <value optimized out> #1 0x00007ffff6477f70 in abort () at abort.c:92 act = {__sigaction_handler = {sa_handler = 0x5068de, sa_sigaction = 0x5068de}, sa_mask = {__val = {140737326326544, 140737233550016, 483, 140737233550256, 140737325461350, 206158430232, 140737233550272, 140737233550048, 140737325372360, 206158430256, 140737233550296, 140737019750384, 117, 117, 0, 140737488347048}}, sa_flags = -162034579, sa_restorer = 0x50a16f} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007ffff646f861 in __assert_fail (assertion=0x5068de "e->e_private == ((void *)0)", file=<value optimized out>, line=483, function=0x506d68 "entry_clean") at assert.c:81 buf = 0x7fffe411a7f0 "slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed.\n" #3 0x000000000043c9f8 in entry_clean (e=0xbcf148) at entry.c:483 __PRETTY_FUNCTION__ = "entry_clean" #4 0x000000000043ca1d in entry_free (e=0x2997) at entry.c:514 No locals. #5 0x00000000004430f7 in slap_send_search_entry (op=0x7fffe4002950, rs=0x7ffff0e81a20) at result.c:1310 berbuf = { buffer = "\000\000\001\000\000\000\000\000?\020", '\000' <repeats 14 times>, "]\240\326\331d\355\343P\000\000\000\000\000\000\000\000]\240\326\331d\355\343Pp\265\211\000\000\000\000\000\354\237C\000\000\000\000\000\200@\000\344\377\177\000\000]\240\326\331d\355\343P\370\360\274\000\000\000\000\000\020\343\177\000\000\000\000\000\200@\000\344\377\177\000\000\v\031E", '\000' <repeats 13 times>, "\004\000\000\000\000\000\000\000\260\375\317\360\377\177", '\000' <repeats 18 times>, "\004", '\000' <repeats 102 times>, ialign = 65536, lalign = 65536, falign = 9.18354962e-41, dalign = 3.2379086165851934e-319, palign = 0x10000 <Address 0x10000 out of bounds>} ber = 0x7fffe4002950 a = 0x80bf90 i = 1 j = <value optimized out> rc = 0 bytes = 8437648 userattrs = 0 acl_state = {as_desc = 0x0, as_access = ACL_NONE, as_vd_acl = 0x0, as_vd_acl_count = 0, as_vd_mask = 1, as_result = -1, as_fe_done = 0} attrsonly = 0 ad_entry = 0x80bf90 e_flags = 0x0 #6 0x00000000004b407c in bdb_search (op=0x7fffe4002950, rs=0x7ffff0e81a20) at search.c:961 bois = {boi_oe = {oe_next = {sle_next = 0x7ffff0e80480}, oe_key = 0x89b570}, boi_txn = 0x0, boi_locks = 0x7ffff0cfff70, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 1 '\001'} blis = {bli_next = 0x0, bli_lock = {off = 398968, ndx = 98, gen = 2, mode = DB_LOCK_READ}, bli_id = 4, bli_flag = 1} scopeok = 1 bdb = 0x89b570 id = 4 cursor = 4 lastid = 18446744073709551615 candidates = {18446744073709551615, 2, 4, 4, 0, 7, 140737019654336, 0, 0, 0, 0, 140737018603728, 0, 398968, 4294967394, 1, 4, 1, 0, 9024880, 0, 140737233551920, 1099511627776, 0 <repeats 31 times>, 140737018605160, 0, 161, 140737018605160, 0, 0, 0, 0, 0, 0, 160, 140737233552240, 0, 0, 0, 4294967394, 1, 0, 0, 0, 7, 140737019654336, 0, 0, 0, 0, 0, 140737019653408, 4159, 140737019655616, 0, 18446744073709551615, 5, 8589934592, 18446744073709551615, 1, 4, 0 <repeats 130981 times>} scopes = {0 <repeats 63786 times>, 64, 0, 0, 0, 0, 0, 64, 0, 0, 206158430210, 532575944795, 140737018593312, 2064, 140737018593312, 2896, 140737019704496, 140737018593416, 140737325535154, 90, 2048, 140737019704256, 80, 6, 32, 4, 0, 2096, 0, 0, 343597383809, 532575944799, 472446402679, 0, 24, 2048, 140737018593312, 2896, 140737019704496, 140737328631424, 140737325539706, 0, 3, 140737235123824, 140737235111168, 140737235111216, 140737235111120, 3, 140737325789440, 140737019662880, 140737019703776, 140737019660544, 140737019662880, 140737019704032, 140737019660544, 140737019662880, 140737019704256, 140737019660544, 140737235123824, 140737235111168, 140737325790836, 8589934594, 140737018603072, 8589934594, 140737019662800, 4294967297, 140737019690064, 8589934594, 140737019662832, 4294967297, 140737019690064, 0 <repeats 502 times>, 17592186044416, 0, 0, 0, 0, 1048576, 0, 0, 18446726481523507198, 18446744073708503039, 18446744073709551615, 18446744073709551615, 0, 16, 0, 0, 18446726477228539902, 18446744073709518831, 18446744073709551615, 18446744073709551615, 0 <repeats 425 times>, 140737325961225, 0, 140737326101420, 90194321408, 0, 3590586904199757824, 140737235118896, 0, 0, 12884908544, 0, 4898288851081953280, 140737235118944, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140737326101420, 562962838323220, 45729780788658, 4294967296, 72058139498840072, 72058139498905608, 122509647347719, 563035852767292, 45729780788658, 12893297154, 4898288846787117064, 4898288846787182600, 9221744489062989832, 3488165888539164681, 257698037760, 5428787749601804308, 36063989980998039, 281509336449045, 562985149158339, 1125935102579651, 844464420836291, 812545396, 0 <repeats 48 times>, 140737325961225, 0, 140737326101420, 90194321408, 0, 3590586904199757824, 140737235119616, 0, 0, 12884908544, 0, 4898288851081953280, 140737235119664, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140737326101420, 562962838323220, 45729780788658, 4294967296, 72058139498840072, 72058139498905608, 122509647347719, 563035852767292...} e = 0xbcf0f8 base = {e_id = 2, e_name = {bv_len = 140737018603856, bv_val = 0x8000 <Address 0x8000 out of bounds>}, e_nname = {bv_len = 16, bv_val = 0x7fffe4103ed0 "ou=users,dc=test"}, e_attrs = 0x44471d, e_ocflags = 5254706, e_bv = {bv_len = 0, bv_val = 0x10000 <Address 0x10000 out of bounds>}, e_private = 0x7fffe41033e0} e_root = <value optimized out> matched = 0x0 ei = 0x7fffe41035c0 realbase = {bv_len = 16, bv_val = 0x7fffe4103ed0 "ou=users,dc=test"} mask = <value optimized out> manageDSAit = <value optimized out> tentries = 3 nentries = <value optimized out> idflag = 0 lock = {off = 398968, ndx = 98, gen = 2, mode = DB_LOCK_READ} opinfo = 0x0 ltid = 0x7fffe4102d20 oex = <value optimized out> #7 0x000000000049db2f in overlay_op_walk (op=0x7fffe4002950, rs=0x7ffff0e81a20, which=<value optimized out>, oi=0x89f650, on=0x0) at backover.c:669 rc = 32768 ... -- BOFH excuse #204: Just pick up the phone and give modem connect sounds. "Well you said we should get more lines so we don't have voice lines."

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 18 Jan '10

18 Jan '10

* alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2009-11-05 07:43:02 +0000]: New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed. I can make a public test server, to let some one check my configs and see faults. Also intresting have any body same failures? > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. > > > #ldd /usr/local/libexec/slapd > /usr/local/libexec/slapd: > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) > libc.so.7 => /lib/libc.so.7 (0x8015f5000) > > > > > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- alexs

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by quanah＠zimbra.com 18 Jan '10

18 Jan '10

--On Tuesday, January 19, 2010 2:02 AM +0000 j(a)gropefruit.com wrote: > I am currently in debug mode with slapd-dbg 2.4.20: > > Having run these commands: > > sudo gdb > handle SIGPIPE nostop=20 > handle SIGPIPE noprint > file /usr/sbin/slapd > set args -d -1 -u openldap -g openldap -h ldapi:/// ldaps:/// ldap:/// = > -f /etc/ldap/slapd.conf > run > > Once it crashes, I will be running: > > thr apply all bt > > After which I will upload the coredump to your FTP server. Just supply the backtrace for now, please. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 18 Jan '10

18 Jan '10

I am currently in debug mode with slapd-dbg 2.4.20: Having run these commands: sudo gdb handle SIGPIPE nostop=20 handle SIGPIPE noprint file /usr/sbin/slapd set args -d -1 -u openldap -g openldap -h ldapi:/// ldaps:/// ldap:/// = -f /etc/ldap/slapd.conf run Once it crashes, I will be running: thr apply all bt After which I will upload the coredump to your FTP server. J On Jan 18, 2010, at 00:58 , Hallvard B Furuseth wrote: > quanah(a)zimbra.com writes: >> Building unix software with debugging symbols is basic system >> administrator knowledge. There is nothing "openldap" specific about >> doing so. >=20 > Yes, there is, since OpenLDAP uses autoconf, libtool & co with = defaults > that get in the way of debugging: >=20 > Openldap 'make install' strips debugging symbols, so you must either = run > slapd from the source tree or install with 'make install STRIP=3D:' or > something, I don't remember at the moment. >=20 > Also it helps debugging to remove the optimize option which OpenLDAP > uses by default if it can compiler-specific, but with gcc that's > ./configure CFLAGS=3D"-g" >=20 >> I would suggest updating = <http://www.openldap.org/faq/data/cache/59.html>=20 >> with any information you feel specifically is lacking. >=20 > I'll make a note to update that one a bit. >=20 > --=20 > Hallvard

1 0

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by masarati＠aero.polimi.it 18 Jan '10

18 Jan '10

> Full_Name: Guillaume Rousse > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.55.250.67) > > The following configuration is supposed to map remote 'homePhone' > attribute to > 'telephoneNumber', and hide remote 'telephoneNumber' attribute: > > database relay > suffix ou=telephony,dc=test > overlay rwm > rwm-suffixmassage ou=users,dc=test > > rwm-map attribute telephoneNumber homePhone > rwm-map attribute telephoneNumber > > However, the server crashes as soon as it has to handle an entry with a > telephoneNumber attribute, as demonstrated with the simple ldif below: > > dn: dc=test > dc: test > objectClass: top > objectClass: domain > > dn: ou=users,dc=test > ou: users > objectClass: top > objectClass: organizationalUnit > > dn: cn=user1,ou=users,dc=test > objectClass: inetOrgPerson > cn: user1 > sn: user1 > > dn: cn=user2,ou=users,dc=test > objectClass: inetOrgPerson > cn: user2 > sn: user2 > telephoneNumber: +33123456789 > > Here is the relevant part of server log, with debugLevel set to trace: > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, > <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: ==> limits_get: conn=1001 op=1 > self="[anonymous]" > this="ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=users,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=users,dc=test>, > <ou=users,dc=test> > Jan 18 13:29:58 slapd[12035]: => bdb_search > Jan 18 13:29:58 slapd[12035]: bdb_dn2entry("ou=users,dc=test") > Jan 18 13:29:58 slapd[12035]: search_candidates: base="ou=users,dc=test" > (0x00000002) scope=2 > Jan 18 13:29:58 slapd[12035]: => bdb_dn2idl("ou=users,dc=test") > Jan 18 13:29:58 slapd[12035]: <= bdb_dn2idl: id=3 first=2 last=4 > Jan 18 13:29:58 slapd[12035]: => bdb_presence_candidates (objectClass) > Jan 18 13:29:58 slapd[12035]: bdb_search_candidates: id=-1 first=2 last=4 > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, > <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 > dn="ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: > <cn=user1,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: > <cn=user1,ou=telephony,dc=test>, <cn=user1,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 > dn="cn=user1,ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: > <cn=user2,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: > <cn=user2,ou=telephony,dc=test>, <cn=user2,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="(null)" Could not reproduce. Apparently, it's something else that's creating hassle. Please provide a stack backtrace. p.

1 0

(ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by Guillaume.Rousse＠inria.fr 18 Jan '10

18 Jan '10

Full_Name: Guillaume Rousse Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) The following configuration is supposed to map remote 'homePhone' attribute to 'telephoneNumber', and hide remote 'telephoneNumber' attribute: database relay suffix ou=telephony,dc=test overlay rwm rwm-suffixmassage ou=users,dc=test rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber However, the server crashes as soon as it has to handle an entry with a telephoneNumber attribute, as demonstrated with the simple ldif below: dn: dc=test dc: test objectClass: top objectClass: domain dn: ou=users,dc=test ou: users objectClass: top objectClass: organizationalUnit dn: cn=user1,ou=users,dc=test objectClass: inetOrgPerson cn: user1 sn: user1 dn: cn=user2,ou=users,dc=test objectClass: inetOrgPerson cn: user2 sn: user2 telephoneNumber: +33123456789 Here is the relevant part of server log, with debugLevel set to trace: Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: ==> limits_get: conn=1001 op=1 self="[anonymous]" this="ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=users,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=users,dc=test>, <ou=users,dc=test> Jan 18 13:29:58 slapd[12035]: => bdb_search Jan 18 13:29:58 slapd[12035]: bdb_dn2entry("ou=users,dc=test") Jan 18 13:29:58 slapd[12035]: search_candidates: base="ou=users,dc=test" (0x00000002) scope=2 Jan 18 13:29:58 slapd[12035]: => bdb_dn2idl("ou=users,dc=test") Jan 18 13:29:58 slapd[12035]: <= bdb_dn2idl: id=3 first=2 last=4 Jan 18 13:29:58 slapd[12035]: => bdb_presence_candidates (objectClass) Jan 18 13:29:58 slapd[12035]: bdb_search_candidates: id=-1 first=2 last=4 Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <cn=user1,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <cn=user1,ou=telephony,dc=test>, <cn=user1,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="cn=user1,ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <cn=user2,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <cn=user2,ou=telephony,dc=test>, <cn=user2,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="(null)"

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by h.b.furuseth＠usit.uio.no 18 Jan '10

18 Jan '10

quanah(a)zimbra.com writes: > Building unix software with debugging symbols is basic system > administrator knowledge. There is nothing "openldap" specific about > doing so. Yes, there is, since OpenLDAP uses autoconf, libtool & co with defaults that get in the way of debugging: Openldap 'make install' strips debugging symbols, so you must either run slapd from the source tree or install with 'make install STRIP=:' or something, I don't remember at the moment. Also it helps debugging to remove the optimize option which OpenLDAP uses by default if it can compiler-specific, but with gcc that's ./configure CFLAGS="-g" > I would suggest updating <http://www.openldap.org/faq/data/cache/59.html> > with any information you feel specifically is lacking. I'll make a note to update that one a bit. -- Hallvard

1 0

(ITS#6456) Feature Request
by j＠gropefruit.com 17 Jan '10

17 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Greetings, Having found out this doesn't already exist as another parameter or configuration method, I am hereby submitting a request for a particular feature. When performing idassert-bind operations, such as with back_ldap, it would be great if an option could be added which would allow specific matched client DNs to be matched and asserted as usual (e.g: the anonymous user asserting to a backend "proxyauthenticator" account) .... while other clients (flagged somehow) would pass-through as themselves. Example (as I might do it for my purposes): idassert-bind bindmethod="simple" binddn="uid=proxyauthenticator,ou=users,dc=example,dc=com" credentials="password_string" starttls="yes" tls_reqcert="never" mode="none" # anonymous clients will assert as "proxyauthenticator", since the backend may not allow anonymous binds. idassert-authzFrom "dn.exact:" # this guy will pass through as himself to the backend, as-is. idassert-passThrough "dn.exact:uid=admin,ou=users,dc=example,dc=com" This would be really helpful, not sure if its difficult to implement ...

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by quanah＠zimbra.com 17 Jan '10

17 Jan '10

--On Sunday, January 17, 2010 10:28 PM +0000 j(a)gropefruit.com wrote: > In general, a page should exist on openldap.org that details, in full, = > the debugging/core dump process and best practices.=20 Building unix software with debugging symbols is basic system administrator knowledge. There is nothing "openldap" specific about doing so. Same with debugging the core files that are generated. Here's a page on basic C compilation: <http://www.cs.rutgers.edu/LCSR-Computing/programming.html> Most specifically, note the "-g" option to CFLAGS, which instructs gcc, in this case, to include debugging symbols in the resulting compiled code. Ensure that when you install, you set STRIP="" so that the "make" program does not strip out the debugging symbols on installation. Run the new slapd that has the debugging information and get a core file. Use GDB to get a backtrace from it. Again, nothing here is specific to OpenLDAP, which is why there is no "OpenLDAP" page on how to do this. I will note the FAQ is fully interactive, allowing anyone to create an entry, if you feel so inclined. I would suggest updating <http://www.openldap.org/faq/data/cache/59.html> with any information you feel specifically is lacking. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 17 Jan '10

17 Jan '10

--Apple-Mail-1--155291042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See my inline changes: On Jan 17, 2010, at 14:13 , masarati(a)aero.polimi.it wrote: > Apart from some changes, I can't reproduce. See comments below. >=20 >> Full_Name: J >> Version: 2.4.20 >> OS: Debian-Lenny/amd64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (68.15.14.98) >>=20 >>=20 >> Host running Debian Lenny amd64 is experiencing a strange issue. = slapd is >> segfaulting for no obvious reason. Syslog output: >>=20 >> Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault = at 40 >> ip >> 7fb2b4829875 sp 44d90940 error 4 in >> back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] >=20 Is there a recommended debugging "practice" you guys recommend? And what = control do I have over the details of our DIT being produced in the core = dump? Security concerns on part of my organization may prevent such a = backtrace ... =3D( > This is not a useful bug report. You should rather follow = instructions > here <http://www.openldap.org/faq/data/cache/56.html> and provide = useful > information. A stack backtrace is essentially mandatory. Also, = details > about the DIT and the exact offending operations would be of help. >=20 >> We are running slapd 2.4.20, via this config: >>=20 >> include /etc/ldap/schema/core.schema >> include /etc/ldap/schema/cosine.schema >> include /etc/ldap/schema/nis.schema >> include /etc/ldap/schema/inetorgperson.schema >>=20 >> pidfile /var/run/slapd/slapd.pid >> argsfile /var/run/slapd/slapd.args >>=20 >> disallow bind_anon >>=20 >> loglevel 0 >> sizelimit 999999 >> idletimeout 10 >>=20 >> modulepath /usr/lib/ldap >> moduleload back_ldap >> moduleload back_hdb >> moduleload pcache >>=20 >> TLSCertificateFile /etc/ldap/ssl/wildcard.crt >> TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key >> TLSCACertificateFile /etc/ldap/ssl/wildcard.pem >>=20 >> database ldap >> uri ldaps://192.168.1.1:636/ >> suffix "ou=3Dsvcs,cn=3Dauth" >> rootdn "uid=3Dslapd,ou=3Dsvcs,cn=3Dauth" >=20 I lied. Our syntax is not cn=3Dauth, I had to sanitize it from what it = really was (security concerns for my company). But thanks for the note. > I note that "cn=3Dauth" should not be used, as this naming context is = used > internally for SASL identities. >=20 >> idassert-bind >> bindmethod=3Dsimple >> binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth" >> credentials=3D"password" >> mode=3Dnone >> idassert-authz=46rom "dn.subtree:ou=3Dsvcs,cn=3Dauth" >>=20 >> ### For some reason, we can no longer use indexes like we could in = slapd >> 2.3 >> ### while using back_ldap (uncommenting these will present slapd from >> starting). >>=20 >> #index objectClass eq >> #index uid,mail,cn eq,sub >> #index queryid eq >=20 Thanks. This is useful to know. > 2.4 is pickier about syntax. "index" has no meaning within back-ldap. = In > 2.3 unrecognized keywords were plainly ignored. >=20 >> overlay pcache >> proxycache hdb 1000 1 50 1200 >> directory "/var/lib/ldap" >> proxycachequeries 100 >> proxyattrset 0 uid mail cn >> proxytemplate (uid=3D) 0 600 >>=20 >> include /etc/ldap/acls.slapd >>=20 >> ########## >>=20 >>=20 >> My hunch, given ITS #6452 (which I remarked was "solved"), is that id >> assertion >> may cause slapd to crash when an identity tries to assert as itself? >>=20 >> e.g: uid=3Dauth,ou=3Dsvcs,cn=3Dauth >--idassert--> = uid=3Dauth,ou=3Dsvcs,cn=3Dauth by >> means >> of the idassert-authz=46rom parameter, which authorizes the entire = subtree >> in >> which this account resides. Again, just a hunch ... >=20 > I had it working auth'ing both as idassert's "binddn" and as another = user > within the allowed subtree. >=20 In general, a page should exist on openldap.org that details, in full, = the debugging/core dump process and best practices.=20 > Please improve the report and feed back. >=20 > p. >=20 --Apple-Mail-1--155291042 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">See = my inline changes:<div><br></div><div><div><div>On Jan 17, 2010, at = 14:13 , <a = href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it</a> = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>Apart from some changes, I can't reproduce.  See = comments below.<br><br><blockquote type=3D"cite">Full_Name: = J<br></blockquote><blockquote type=3D"cite">Version: = 2.4.20<br></blockquote><blockquote type=3D"cite">OS: = Debian-Lenny/amd64<br></blockquote><blockquote type=3D"cite">URL: <a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br></blockquote><blockquote type=3D"cite">Submission from: (NULL) = (68.15.14.98)<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Host running = Debian Lenny amd64 is experiencing a strange issue.  slapd = is<br></blockquote><blockquote type=3D"cite">segfaulting for no obvious = reason. Syslog output:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Jan 15 19:29:59 = ldapc1 kernel: [10702.262741] slapd[3218]: segfault at = 40<br></blockquote><blockquote = type=3D"cite">ip<br></blockquote><blockquote type=3D"cite">7fb2b4829875 = sp 44d90940 error 4 in<br></blockquote><blockquote = type=3D"cite">back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000]<br></blockquote><= br></div></blockquote><div>Is there a recommended debugging "practice" = you guys recommend? And what control do I have over the details of our = DIT being produced in the core dump?  Security concerns on part of = my organization may prevent such a backtrace ... =3D(</div><br><blockquote= type=3D"cite"><div>This is not a useful bug report.  You should = rather follow instructions<br>here <<a = href=3D"http://www.openldap.org/faq/data/cache/56.html">http://www.openlda= p.org/faq/data/cache/56.html</a>> and provide useful<br>information. =  A stack backtrace is essentially mandatory.  Also, = details<br>about the DIT and the exact offending operations would be of = help.<br><br><blockquote type=3D"cite">We are running slapd 2.4.20, via = this config:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/core.sche= ma<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/cosine.sc= hema<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/nis.schem= a<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/inetorgpe= rson.schema<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">pidfile =         /var/run/slapd/slapd.pid<b= r></blockquote><blockquote type=3D"cite">argsfile =        /var/run/slapd/slapd.args<br></b= lockquote><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite">disallow =        bind_anon<br></blockquote><block= quote type=3D"cite"><br></blockquote><blockquote type=3D"cite">loglevel =        0<br></blockquote><blockquote = type=3D"cite">sizelimit =       999999<br></blockquote><blockquote = type=3D"cite">idletimeout =     10<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">modulepath =      /usr/lib/ldap<br></blockquote><blockquote = type=3D"cite">moduleload =      back_ldap<br></blockquote><blockquote = type=3D"cite">moduleload =      back_hdb<br></blockquote><blockquote = type=3D"cite">moduleload =      pcache<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">TLSCertificateFile =      /etc/ldap/ssl/wildcard.crt<br></blockquote><= blockquote type=3D"cite">TLSCertificateKeyFile =   /etc/ldap/ssl/wildcard.key<br></blockquote><blockquote = type=3D"cite">TLSCACertificateFile =    /etc/ldap/ssl/wildcard.pem<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">database =        ldap<br></blockquote><blockquote= type=3D"cite">uri =             <a= = href=3D"ldaps://192.168.1.1:636/">ldaps://192.168.1.1:636/</a><br></blockq= uote><blockquote type=3D"cite">suffix =          "ou=3Dsvcs,cn=3Dauth= "<br></blockquote><blockquote type=3D"cite">rootdn =          "uid=3Dslapd,ou=3Dsv= cs,cn=3Dauth"<br></blockquote><br></div></blockquote><div><br></div><div>I= lied. Our syntax is not cn=3Dauth, I had to sanitize it from what it = really was (security concerns for my company).  But thanks for the = note.</div><br><blockquote type=3D"cite"><div>I note that "cn=3Dauth" = should not be used, as this naming context is used<br>internally for = SASL identities.<br><br><blockquote = type=3D"cite">idassert-bind<br></blockquote><blockquote type=3D"cite"> =   bindmethod=3Dsimple<br></blockquote><blockquote type=3D"cite">= =   binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth"<br></blockquote><blo= ckquote type=3D"cite"> =   credentials=3D"password"<br></blockquote><blockquote = type=3D"cite">   mode=3Dnone<br></blockquote><blockquote = type=3D"cite">idassert-authz=46rom = "dn.subtree:ou=3Dsvcs,cn=3Dauth"<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">### For some = reason, we can no longer use indexes like we could in = slapd<br></blockquote><blockquote = type=3D"cite">2.3<br></blockquote><blockquote type=3D"cite">### while = using back_ldap (uncommenting these will present slapd = from<br></blockquote><blockquote = type=3D"cite">starting).<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">#index =           objectClass =    eq<br></blockquote><blockquote type=3D"cite">#index =          uid,mail,cn =     eq,sub<br></blockquote><blockquote = type=3D"cite">#index =          queryid =         eq<br></blockquote><br></d= iv></blockquote><div><br></div><div>Thanks.  This is useful to = know.</div><br><blockquote type=3D"cite"><div>2.4 is pickier about = syntax.  "index" has no meaning within back-ldap.  In<br>2.3 = unrecognized keywords were plainly ignored.<br><br><blockquote = type=3D"cite">overlay =             &n= bsp;   pcache<br></blockquote><blockquote = type=3D"cite">proxycache =             &n= bsp;hdb 1000 1 50 1200<br></blockquote><blockquote type=3D"cite">directory= =             &n= bsp; "/var/lib/ldap"<br></blockquote><blockquote = type=3D"cite">proxycachequeries =       100<br></blockquote><blockquote = type=3D"cite">proxyattrset =            0 uid = mail cn<br></blockquote><blockquote type=3D"cite">proxytemplate =           (uid=3D) =  0 600<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =             &n= bsp;   /etc/ldap/acls.slapd<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">##########<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">My hunch, given = ITS #6452 (which I remarked was "solved"), is that = id<br></blockquote><blockquote = type=3D"cite">assertion<br></blockquote><blockquote type=3D"cite">may = cause slapd to crash when an identity tries to assert as = itself?<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">e.g: = uid=3Dauth,ou=3Dsvcs,cn=3Dauth >--idassert--> = uid=3Dauth,ou=3Dsvcs,cn=3Dauth by<br></blockquote><blockquote = type=3D"cite">means<br></blockquote><blockquote type=3D"cite">of the = idassert-authz=46rom parameter, which authorizes the entire = subtree<br></blockquote><blockquote = type=3D"cite">in<br></blockquote><blockquote type=3D"cite">which this = account resides.  Again, just a hunch = ...<br></blockquote><br></div></blockquote><blockquote = type=3D"cite"><div>I had it working auth'ing both as idassert's "binddn" = and as another user<br>within the allowed = subtree.<br><br></div></blockquote><div><br></div><div>In general, a = page should exist on <a href=3D"http://openldap.org">openldap.org</a> = that details, in full, the debugging/core dump process and best = practices. </div><div><br></div><blockquote type=3D"cite"><div>Please= improve the report and feed back.<br><font class=3D"Apple-style-span" = color=3D"#000000"><font class=3D"Apple-style-span" = color=3D"#144FAE"><br></font></font></div></blockquote><blockquote = type=3D"cite"><div>p.<br><br></div></blockquote></div><br></div></body></h= tml>= --Apple-Mail-1--155291042--

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by masarati＠aero.polimi.it 17 Jan '10

17 Jan '10

Apart from some changes, I can't reproduce. See comments below. > Full_Name: J > Version: 2.4.20 > OS: Debian-Lenny/amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) > > > Host running Debian Lenny amd64 is experiencing a strange issue. slapd is > segfaulting for no obvious reason. Syslog output: > > Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault at 40 > ip > 7fb2b4829875 sp 44d90940 error 4 in > back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] This is not a useful bug report. You should rather follow instructions here <http://www.openldap.org/faq/data/cache/56.html> and provide useful information. A stack backtrace is essentially mandatory. Also, details about the DIT and the exact offending operations would be of help. > We are running slapd 2.4.20, via this config: > > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > > pidfile /var/run/slapd/slapd.pid > argsfile /var/run/slapd/slapd.args > > disallow bind_anon > > loglevel 0 > sizelimit 999999 > idletimeout 10 > > modulepath /usr/lib/ldap > moduleload back_ldap > moduleload back_hdb > moduleload pcache > > TLSCertificateFile /etc/ldap/ssl/wildcard.crt > TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key > TLSCACertificateFile /etc/ldap/ssl/wildcard.pem > > database ldap > uri ldaps://192.168.1.1:636/ > suffix "ou=svcs,cn=auth" > rootdn "uid=slapd,ou=svcs,cn=auth" I note that "cn=auth" should not be used, as this naming context is used internally for SASL identities. > idassert-bind > bindmethod=simple > binddn="uid=auth,ou=svcs,cn=auth" > credentials="password" > mode=none > idassert-authzFrom "dn.subtree:ou=svcs,cn=auth" > > ### For some reason, we can no longer use indexes like we could in slapd > 2.3 > ### while using back_ldap (uncommenting these will present slapd from > starting). > > #index objectClass eq > #index uid,mail,cn eq,sub > #index queryid eq 2.4 is pickier about syntax. "index" has no meaning within back-ldap. In 2.3 unrecognized keywords were plainly ignored. > overlay pcache > proxycache hdb 1000 1 50 1200 > directory "/var/lib/ldap" > proxycachequeries 100 > proxyattrset 0 uid mail cn > proxytemplate (uid=) 0 600 > > include /etc/ldap/acls.slapd > > ########## > > > My hunch, given ITS #6452 (which I remarked was "solved"), is that id > assertion > may cause slapd to crash when an identity tries to assert as itself? > > e.g: uid=auth,ou=svcs,cn=auth >--idassert--> uid=auth,ou=svcs,cn=auth by > means > of the idassert-authzFrom parameter, which authorizes the entire subtree > in > which this account resides. Again, just a hunch ... I had it working auth'ing both as idassert's "binddn" and as another user within the allowed subtree. Please improve the report and feed back. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs