openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (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 25 Apr '09

25 Apr '09

Hallvard B Furuseth schrieb: > Yes, the on-th-fly sorting combined with the delete-single-value > code seems broken. I'm not sure if delete-single-value could ever > be invoked Of course could it be "invoked" before: just use slapd 2.4.16 together with slapo-collect and your favorit ldapmodify client. Right after the "invocation" you'll get an error message complaining about a missing equality rule. Thus there's no hint within collect's source that the single-value delete is faulty I inserted an equality rule and began to wonder... > before you inserted an EQUALITY matching rule though. Do you mean the single-value-delete functionality has been silently "disabled" by removing the EQUALITY matching rule leaving slapo-collect's by design defective single-value-delete code block knowingly unchanged/uncommented? This seems very strange to me even more because slapo-collect is advertises as demonstration overlay (ok, a "quick hacked" one but nevertheless questionable). > I too don't know cn=config all that well:-( <speculation> Instead of correcting handling this issue only in collect.c there perhabs exists a more general possibility to pimp the cn=config internal add mechanisms regarding the handling of ordered config values? In my opinion a very important feature concerning "overlapping"... Á la: cfg_value_add(.., .., SLAPD_CFG_VALSORT_ALPHA|SLAPD_CFG_VALSORT_DN|..) only problem seems to be how to sort a configuration value like: '"ou=test,dc=foo,dc=bar" l,st' by DN's depth </speculation>

1 0

(ITS#5535) smbk5pwd uses private heimdal functions
by admin＠dmarkey.com 24 Apr '09

24 Apr '09

--000e0cd1e8fc2040e9046856eee5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review http://dmarkey.com/~dmarkey/smbk5pwd.patch to fix this. Against 2.4.16 smbk5pwd. --000e0cd1e8fc2040e9046856eee5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please review <a href="http://dmarkey.com/~dmarkey/smbk5pwd.patch">http://dmarkey.com/~dmarkey/smbk5pwd.patch</a> to fix this.<br><br>Against 2.4.16 smbk5pwd.<br><br><br> --000e0cd1e8fc2040e9046856eee5--

1 0

(ITS#6077) Spurious uniqueness errors with filters in unique overlays
by andres＠anarazel.de 24 Apr '09

24 Apr '09

Full_Name: Andres Freund Version: 2.4.16 OS: Linux URL: Submission from: (NULL) (85.178.193.10) If I read the code correctly the unique overlay does not check if the current operation matches the filter of a domain before doing a uniqeness check. This leads to wrongly reported errors. I noticed this after adding a uniqueness constraint on gidNumber on all posixGroup objects (i.e. ldap:///?gidNumber?sub?(objectClass=posixGroup)) - it was not possible anymore to add posixAccounts with that gidNumber. Thanks, Andres Here a modification of the testscript to reproduce the issue: --- openldap-2.4.16.saved/tests/scripts/test024-unique 2009-04-23 23:51:37.942051631 +0200 +++ openldap-2.4.16/tests/scripts/test024-unique 2009-04-25 02:50:40.975257488 +0200 @@ -425,6 +425,7 @@ changetype: modify add: olcUniqueURI olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) - delete: olcUniqueURI olcUniqueURI: ldap:///?description?one @@ -445,6 +446,7 @@ olcOverlay: {0}unique olcUniqueURI: ldap:///?employeeNumber,displayName?sub olcUniqueURI: ldap:///?sn?sub?(cn=e*) +olcUniqueURI: ldap:///?uid?sub?(cn=edgar) EOF diff $TESTDIR/third-config.ldif $TESTDIR/third-reference.ldif > /dev/null 2>&1 @@ -473,6 +475,27 @@ exit -1 fi + +echo "Adding a record unique in all domains because of filter conditions " + +$LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \ + $TESTOUT 2>&1 << EOF +dn: uid=empty,ou=users,o=unique +objectClass: inetOrgPerson +uid: edgar +cn: empty +sn: empty +EOF + +RC=$? +if test $RC != 0 ; then + echo "spurious unique error ($RC)!" + test $KILLSERVERS != no && kill -HUP $KILLPIDS + exit -1 +fi + + + echo "Adding a record unique in one domain, non-unique in the filtered domain..." $LDAPADD -D "$UNIQUEDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \

1 0

24 Apr '09

Yes, the on-th-fly sorting combined with the delete-single-value code seems broken. I'm not sure if delete-single-value could ever be invoked before you inserted an EQUALITY matching rule though. I too don't know cn=config all that well:-( -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

oops, lost a few words: I wrote: > I'll fix that and a few other comments and close this ITS, > since you've clarified issue here in ITS#6076. Since you've clarified _the other_ issue here in ITS#6076. -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 24 Apr '09

24 Apr '09

Daniel Pluta writes: > cite: "... this means longer dn's (i.e. more specific dn's) will be > found first when searching..." > > But, longer DNs do not neccessarily are more specific: > > ou=openldap,o=rockz,c=it > dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific) It's just the comment which is unclear. It should be saying that sorting normalized DNs by reverse length ensures that a DN is stored after any of its subordinate DNs. I'll fix that and a few other comments and close this ITS, since you've clarified issue here in ITS#6076. -- Hallvard

1 0

(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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs