openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

(ITS#6076)
by Daniel.Pluta＠lrz.de 24 Apr '09

24 Apr '09

sorry, there's a small cut&paste error regarding step 12.) Please ignore the first 4 lines. Only the last two lines contain the corresponding output regarding step 11.) Thanks!

1 0

(ITS#6076) slapo-collect: slapd repeatable segfaults caused by deletion of a single olcCollectInfo config value (when olcCollectInfo contains multiple configuration values)
by daniel＠pluta.biz 24 Apr '09

24 Apr '09

Full_Name: Daniel Pluta Version: OPENLDAP_STABLE OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090424.patch Submission from: (NULL) (2001:4ca0:0:f000:ecb9:edd3:5b88:63f0) As already assumed in (ITS6072 FollowUp 5) there seems to be a bug regarding the mapping of c->valx and the to-be-deleted value of the ci->ci_next list. The origin seems to be the on-the-fly manipulation (sorting) of the ci-list that is done by insert_ordered()) whenever a new config value is added... To illustrate the problem in detail I've added some debugging output into collect.c's LDAP_MOD_DELETE-section: case LDAP_MOD_DELETE: if ( c->valx == -1 ) { /* Delete entire attribute */ collect_info *ci; while (( ci = on->on_bi.bi_private )) { on->on_bi.bi_private = ci->ci_next; ch_free( ci->ci_dn.bv_val ); ch_free( ci ); } } else { /* Delete just one value */ collect_info **cip, *ci; int i; cip = (collect_info **)&on->on_bi.bi_private; Debug(LDAP_DEBUG_TRACE, "collect_cf: LDAP_MOD_DELETE: c->valx=%d\n", c->valx, 0, 0); for ( i=0; i <= c->valx; i++, cip = &ci->ci_next ) { ci = *cip; Debug(LDAP_DEBUG_TRACE, "collect_cf: LDAP_MOD_DELETE: i=%d <--> dn=%s\n", i, ci->ci_dn.bv_val, 0); } *cip = ci->ci_next; Debug(LDAP_DEBUG_TRACE, "collect_cf: free: dn=%s\n", ci->ci_dn.bv_val, 0, 0); ch_free( ci->ci_dn.bv_val ); ch_free( ci ); } The patch against OPENLDAP_STABLE could be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-090424.patch This patch also includes the mini-enhancement proposed in ITS6072 and the micro-bugfix provided in ITS6075. ITS6075 solves a small schema-specific bug which wrongly denied deletion of single olcCollectInfo configuration values at all. Here are my 12 steps to reproduce the crash... 1.) edit collect's configuration setup in slapd.conf by adding the following lines: overlay collect collectinfo ou=customer_A,dc=foo,dc=bar l,st collectinfo ou=customer_B,dc=foo,dc=bar l,st collectinfo ou=customer_C,dc=foo,dc=bar l,st collectinfo ou=customer_D,dc=foo,dc=bar l,st collectinfo ou=customer_E,dc=foo,dc=bar l,st collectinfo ou=customer_F,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_A,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_B,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_C,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_D,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_E,dc=foo,dc=bar l,st collectinfo ou=users,ou=customer_F,dc=foo,dc=bar l,st 2.) convert ".conf" into "cn=config" format, by running: slaptest -f ... -F ... The resulting collect cn=config ldif should be similar to: dn: olcOverlay={0}collect objectClass: olcOverlayConfig objectClass: olcCollectConfig olcOverlay: {0}collect olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_a,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_a,dc=foo,dc=bar" l,st structuralObjectClass: olcCollectConfig entryUUID: 51c7d5fa-c50a-102d-9657-f3a43e5eeda2 creatorsName: cn=config createTimestamp: 20090424105633Z entryCSN: 20090424105633.913345Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090424105633Z 3.) start slapd using the generated config (slapd -F ...) 4.) start browsing cn=config everything is fine 5.) delete the follwing olcCollectInfo Value using this ldif: dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=customer_a,dc=foo,dc=bar" l,st - 6.) examine the log based on the above patch (which delivers the following debugging output) collect_cf: LDAP_MOD_DELETE: c->valx=11 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=1 <--> dn=ou=users,ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=2 <--> dn=ou=users,ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=3 <--> dn=ou=users,ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=4 <--> dn=ou=users,ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=5 <--> dn=ou=users,ou=customer_f,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=6 <--> dn=ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=7 <--> dn=ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=8 <--> dn=ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=9 <--> dn=ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=10 <--> dn=ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=11 <--> dn=ou=customer_f,dc=foo,dc=bar collect_cf: free: dn=ou=customer_f,dc=foo,dc=bar ==> Holy sh..! ou=customer_f,dc=foo,dc=bar has been deleted, instead?!?!?! 7.) Though slapd still runs, lets ask about some more details using ldapsearch: dn: olcoverlay={0}collect,olcdatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcCollectConfig olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_b,dc=foo,dc=bar" l,st olcCollectInfo: "ou=users,ou=customer_a,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_f,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_d,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_c,dc=foo,dc=bar" l,st olcCollectInfo: "ou=customer_b,dc=foo,dc=bar" l,st olcOverlay: {0}collect ==> Impressive! It seems to be that ou=customer_a,dc=foo,dc=bar has been deleted(?!?!) 8.) ok, once again we try to delete a value: dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=customer_e,dc=foo,dc=bar" l,st - 9.) but the logging output tells us: "customer_b" gets deleted now... collect_cf: LDAP_MOD_DELETE: c->valx=7 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=1 <--> dn=ou=users,ou=customer_b,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=2 <--> dn=ou=users,ou=customer_c,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=3 <--> dn=ou=users,ou=customer_d,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=4 <--> dn=ou=users,ou=customer_e,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=5 <--> dn=ou=users,ou=customer_f,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=6 <--> dn=ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: i=7 <--> dn=ou=customer_b,dc=foo,dc=bar collect_cf: free: dn=ou=customer_b,dc=foo,dc=bar 10.) analog to point 7.) ldapsearch reports "customer_e" has been deleted... 11.) so far so good, now lets try to increase our level of fun and delete another olcCollectInfo-value: #!RESULT OK #!CONNECTION ldap://10.111.1.1:3890 #!DATE 2009-04-24T11:36:18.343 dn: olcOverlay={0}collect,olcDatabase={2}bdb,cn=config changetype: modify delete: olcCollectInfo olcCollectInfo: "ou=users,ou=customer_f,dc=foo,dc=bar" l,st - 12.) slapd immediatly crashes, the logging output shows: collect_cf: LDAP_MOD_DELETE: c->valx=0 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: free: i=1 <--> dn=ou=users,ou=customer_a,dc=foo,dc=bar collect_cf: LDAP_MOD_DELETE: c->valx=6 collect_cf: LDAP_MOD_DELETE: i=0 <--> dn=(null) ==> segfault, ZONK! In my opinion it seems that the crash depends on the on-th-fly sorting of the DN-list which directly depends on the timely order the DNs have been added (processed by "insert_ordered()"). I'm not sure how to "fix" this bug providing an elegant solution because I don't understand the direct/slapd-internal mapping of i to ci->cn_next in detail (usually ldap results are unordered, perhabs something special regarding back-config?). The problem seems to be located here: for ( i=0; i <= c->valx; i++, cip = &ci->ci_next ) These were my two first thoughts regarding a possible workaround: - Always deleting and adding all values, in case one value gets modified? - Using ordered-format "{n}" seems to result in "always delete / add all values", too. I would appreciate your advice!

1 0

Re: (ITS#5382) JLDAP
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__PartF5DD40B7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Jim, We have fixed the issue . We will be checking the same . Thanks for = identifying the issue . =20 regards Arpit=20 =20 --=__PartF5DD40B7.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Jim,</DIV> <DIV>    We have fixed the issue . We will be checking the = same . Thanks for identifying the issue .</DIV> <DIV> </DIV> <DIV>regards</DIV> <DIV>Arpit </DIV> <DIV> </DIV></BODY></HTML> --=__PartF5DD40B7.0__=--

1 0

Re: (ITS#5389) Contribution: JLDAP support for password policy response control
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__Part133BA653.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Raymond , =20 This is just for my understanding . Is Password Policy response is a = standard ? What is the requirement of this particular feature to be = present in JLDAP? What is this feature and how it can be used ?=20 We can take it in if this is a standard but if this is not a standard = than we cannot take this in as this will make the code bulkier.=20 =20 regards, Arpit=20 --=__Part133BA653.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Raymond ,</DIV> <DIV> </DIV> <DIV>   This is just for my understanding . Is Password Policy = response is a standard ? What is the requirement of this particular = feature to be present in JLDAP? What is this feature and how it can be = used ? </DIV> <DIV>   We can take it in if this is a standard but if this is = not a standard than we cannot take this in as this will make the code = bulkier. </DIV> <DIV> </DIV> <DIV>regards,<BR>Arpit </DIV></BODY></HTML> --=__Part133BA653.0__=--

1 0

Re: (ITS#6071) LDAP server becomes unresponsive
by carsten.rieck＠trustcenter.de 24 Apr '09

24 Apr '09

Hello, the update to OpenLDAP 2.4.16 has solved my problem with the unresponsive server. Quanah, thank you very much for your help. From my point of view, the ITS can be closed. Best regards, Carsten -- Dr. Carsten T. Rieck Development TC TrustCenter GmbH Sonninstrasse 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40-808026-0, Fax: -126 Geschaeftsfuehrung/Managing Directors: Robert Steinkrauss , Dr. Sabine Kockskaemper , HRB 96168 Email: carsten.rieck(a)trustcenter.de www.trustcenter.de This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies.

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder schrieb: > daniel(a)pluta.biz wrote: >> I could not find a suitable api-call to determine a DN's depth. > > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: > > I guess reg ex splitting won't work for arbitrary DN strings. > > Ciao, Michael. I finaly managed to upload the patch under "incoming/collect.c.patch" Instead of using posix regexp I've used the ldap_bv2dn() based methode recommended by you. I would appreciate your revise. This patch does not include slapo-collect's schema-patch that I've filed some minutes ago (see: ITS#6075) Thanks!

1 0

(ITS#6075) slapo-collect: olcCollectInfo: no equality matching rule
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Full_Name: Daniel Pluta Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch Submission from: (NULL) (91.12.202.8) It's impossible to delete one value from the multi-valued olcCollectInfo in case there are more than 1 olcCollectInfo values configured... Error: "olcCollectInfo: no equality matching rule" I've uploaded a small patch here: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch I'm not sure whether ORDERING and SUBSTRINGMATCH are neccessary, optional or even wrong(?). Perhab's they can (have to?) be omitted - please see below... Index: ldap/servers/slapd/overlays/collect.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/collect.c,v retrieving revision 1.5.2.8 diff -u -r1.5.2.8 collect.c --- ldap/servers/slapd/overlays/collect.c 22 Jan 2009 00:01:12 -0000 1.5.2.8 +++ ldap/servers/slapd/overlays/collect.c 23 Apr 2009 20:00:02 -0000 @@ -230,6 +230,9 @@ ARG_MAGIC, collect_cf, "( OLcfgOvAt:19.1 NAME 'olcCollectInfo' " "DESC 'DN of entry and attribute to distribute' " + "EQUALITY caseIgnoreMatch " + "ORDERING caseIgnoreOrderingMatch " + "SUBSTR caseIgnoreSubstringsMatch " "SYNTAX OMsDirectoryString )", NULL, NULL }, { NULL, NULL, 0, 0, 0, ARG_IGNORED } };

1 0

Re: (ITS#6073) ftp.openldap.org "no space left on device"?
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Status update: it has been fixed - proved by me with: ftp> put daniel-pluta-090423.patch local: daniel-pluta-090423.patch remote: daniel-pluta-090423.patch 227 Entering Passive Mode (204,152,186,57,229,234) 150 Opening BINARY mode data connection for 'daniel-pluta-090423.patch'. 226 Transfer complete (unique file name:daniel-pluta-090423.patch). 735 bytes sent in 0.00 secs (413.2 kB/s) Thanks for addressing/solving this issue. Kurt Zeilenga schrieb: > This problem as been addressed. > > -- Kurt > > On Apr 22, 2009, at 7:45 AM, daniel(a)pluta.biz wrote: > >> Full_Name: Daniel Pluta >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) >> >> >> ~/build/pkg$ ftp -p 204.152.186.57 >> Connected to 204.152.186.57. >> 220- OpenLDAP FTP Service >> 220 boole.openldap.org FTP server (Version 6.00LS) ready. >> Name (204.152.186.57:d): anonymous >> 331 Guest login ok, send your email address as password. >> Password: >> 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights Reserved. >> 230- COPYING RESTRICTIONS APPLY, see: >> 230- ftp://ftp.openldap.org/COPYRIGHT >> 230- ftp://ftp.openldap.org/LICENSE >> 230 Guest login ok, access restrictions apply. >> Remote system type is UNIX. >> Using binary mode to transfer files. >> ftp> cd incoming >> 250 CWD command successful. >> ftp> put collect.c.patch >> local: collect.c.patch remote: collect.c.patch >> 227 Entering Passive Mode (204,152,186,57,240,13) >> 150 Opening BINARY mode data connection for 'collect.c.patch.3'. >> 452 Error writing to file: No space left on device. >> 1833 bytes sent in 0.00 secs (1361.2 kB/s) >> ftp> >

1 0

Re: (ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-its6074-bt.txt

1 0

(ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

Full_Name: Aaron Richton Version: 2.4.16 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Still going through the logs to see what slapd was doing at the time, but my expectation is "Nothing Particularly Exciting" -- this was under production load, I wasn't poking it with a stick or anything. URI with backtrace to follow...

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs