- openldap-bugs - openldap.org

Re: (ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com 15 Jun '11

15 Jun '11

I'm unable to reproduce this problem with the latest syncrepl.c from git.

1 0

Re: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com 15 Jun '11

15 Jun '11

--_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sorry=2C I mistyped my email address=2C it should be ctcard(a)hotmail.com = = --_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> sorry=2C I mistyped my email address=2C it should be ctcard(a)hotmail.com = </body> </html>= --_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_--

1 0

Fwd: Re: (ITS#6968) Glue objectclass created during Grouper provisioning
by hyc＠symas.com 15 Jun '11

15 Jun '11

User error, closing. -------- Original Message -------- Subject: Re: (ITS#6968) Glue objectclass created during Grouper provisioning Date: Wed, 15 Jun 2011 10:40:32 +0100 From: Mark Cairney <Mark.Cairney(a)ed.ac.uk> To: Howard Chu <hyc(a)symas.com> Hi, > > Then please strip out those attributes and objectclasses and verify that the LDIF file still reproduces the problem. I can't do this at the moment as this system will be going live imminently however I think I've tracked down the root cause of the problem. One of our servers was going to Redhat for it's NTP sync rather than the same local source as the others so it's clock was slightly skewed in relation. The issue now seems to no longer be occuring having thrown some fairly large LDIFs as the server as a test. >> > Just clicking on the link in any web browser. Also using the link with wget. Either way authentication is requested. >> I've moved the zip if you still want to take a look but given the cause I'm happy for the issue to be closed. IMO it was probably premature raising it as a bug but I was advised to on the list! I'll reply to my post on the list with the cause/solution for completeness. Kind regards, Mark -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmal.com 14 Jun '11

14 Jun '11

Full_Name: Chris Card Version: 2.4.23 OS: Centos 5.4 URL: Submission from: (NULL) (91.194.158.133) I am running slapd with a bdb back end, and using ldapsearch to query it. My ldapsearch command looks like this: ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 which returns the first 11 records and then prompts: # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.474 false MAMKAQA= sortResult: (0) Success control: 2.16.840.1.113730.3.4.10 false MA8CAQACATkCAQAEBOhhowg= vlvResult: pos=0 count=57 context=6GGjCA== (0) Success # numResponses: 12 # numEntries: 11 Press [before/after(/offset/count|:value)] Enter for the next window. Then, when I press Enter ldapsearch outputs the following and exits: # extended LDIF # # LDAPv3 # base <......> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/10/57 # # search result search: 3 result: 4 Size limit exceeded # numResponses: 1 If I then try the search again ldapsearch outputs: # extended LDIF # # LDAPv3 # base <......> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/0/10 # # search result search: 2 result: 51 Server is busy text: Other sort requests already in progress # numResponses: 1 The "Size limit exceeded" error appears to come from slap_send_search_entry() in result.c: if ( op->ors_slimit >= 0 && rs->sr_nentries >= op->ors_slimit ) { return LDAP_SIZELIMIT_EXCEEDED; } because op->ors_slimit is 0 instead of SLAP_NO_LIMIT (-1). If I do the ldapsearch with an explicit size limit, using the -z flag, e.g. ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 -z 20 then I don't get the "Size limit exceeded" error, and all the records are output by ldapsearch with a prompt after each set of 11 records, but after all the records have been output there is a different error before ldapsearch exits: # extended LDIF # # LDAPv3 # base <dc=blackspider,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/60/57 # # search result search: 8 result: 76 Virtual List View error control: 2.16.840.1.113730.3.4.10 false MA8CATICATkCAU0EBHBFIQo= vlvResult: pos=50 count=57 context=cEUhCg== (77) Unknown error # numResponses: 1 and again a subsequent ldapsearch request gets the "Server is busy" error.

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by hyc＠symas.com 14 Jun '11

14 Jun '11

Timo Teräs wrote: > On 06/14/2011 08:24 AM, hyc(a)symas.com wrote: >> On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: >>> On 06/13/2011 11:56 PM, Howard Chu wrote: >>>> timo.teras(a)iki.fi wrote: >>>>> ITS#6691 seems to be same issue. >>>>> >>>>> I have a patch to fix this. >>>>> >>>>> It's available at: >>>>> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… >>>>> >>>> Thanks for the patch, now in git master. >>> >>> Good. Though, it would have been polite to credit me as the commit author. >> >> You were credited in the release branch. > > Oh, right. > >> In the future use git format-patch and things like this won't get overlooked. > > I did not have the git tree available on the 64-bit machine I was given > to work with. And at that point I did not even know which version > control you used. You are expected to have read this already before submitting code: http://www.openldap.org/devel/contributing.html -- -- 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#6657) back-sql segfault in backsql_search
by timo.teras＠iki.fi 13 Jun '11

13 Jun '11

On 06/14/2011 08:24 AM, hyc(a)symas.com wrote: > On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: >> On 06/13/2011 11:56 PM, Howard Chu wrote: >>> timo.teras(a)iki.fi wrote: >>>> ITS#6691 seems to be same issue. >>>> >>>> I have a patch to fix this. >>>> >>>> It's available at: >>>> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… >>>> >>> Thanks for the patch, now in git master. >> >> Good. Though, it would have been polite to credit me as the commit author. > > You were credited in the release branch. Oh, right. > In the future use git format-patch and things like this won't get overlooked. I did not have the git tree available on the 64-bit machine I was given to work with. And at that point I did not even know which version control you used. git commit does have --author="" switch, so it's very easy to set the patch author properly even if it's not in git patch format.

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by hyc＠symas.com 13 Jun '11

13 Jun '11

On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: > On 06/13/2011 11:56 PM, Howard Chu wrote: > > timo.teras(a)iki.fi wrote: > >> ITS#6691 seems to be same issue. > >> > >> I have a patch to fix this. > >> > >> It's available at: > >> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… > >> > > Thanks for the patch, now in git master. > > Good. Though, it would have been polite to credit me as the commit author. You were credited in the release branch. In the future use git format-patch and things like this won't get overlooked. > > Thanks, > Timo

1 0

RE: (ITS#6964) ./configure bug when specifying openssl as the TLS library to use
by the_uhu＠hotmail.com 13 Jun '11

13 Jun '11

--_d1f53d59-c756-486d-94a1-c6fa39a61c52_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C Am wondering what I am missing here? Because to get OpenLDAP to compile wit= h openssl as the TLS library to use=2C I had change this line. You said that line 19408 on your copy of configure is not the LIBS line bel= ow even though I downloaded openldap fresh - could you offer an explanation= please? Paul. From: the_uhu(a)hotmail.com To: openldap-its(a)openldap.org Subject: RE: (ITS#6964) ./configure bug when specifying openssl as the TLS = library to use Date: Thu=2C 9 Jun 2011 00:16:10 +0000 I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAglue -lrsaref $LIBS" Also checked the source repository on the website and it's there also. Can you please double check? Paul. > Date: Wed=2C 8 Jun 2011 22:13:55 +0000 > From: openldap-its(a)OpenLDAP.org > To: the_uhu(a)hotmail.com > Subject: Re: (ITS#6964) ./configure bug when specifying openssl as the TL= S library to use >=20 > I don't know where your configure script came from=2C but there's nothing= related > to OpenSSL at line 19408 of the current released configure script=2C and = our > script has had logic to detect -lrsaref since 1999. >=20 > Closing this ITS. Use the actual configure script supplied by the OpenLDA= P > Project. = --_d1f53d59-c756-486d-94a1-c6fa39a61c52_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> Hi=2C Am wondering what I am missing here? Because to get OpenLDAP t= o compile with openssl as the TLS library to use=2C I had change this line.= You said that line 19408 on your copy of configure is not the LIBS = line below even though I downloaded openldap fresh - could you offer an exp= lanation please? Paul. <hr id=3D"stopSpelling">From: the_uhu@= hotmail.com To: openldap-its(a)openldap.org Subject: RE: (ITS#6964) ./c= onfigure bug when specifying openssl as the TLS library to use Date: Thu= =2C 9 Jun 2011 00:16:10 +0000 <meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dunicode= "> <meta name=3D"Generator" content=3D"Microsoft SafeHTML"> <style> .ExternalClass .ecxhmmessage P {padding:0px=3B} .ExternalClass body.ecxhmmessage {font-size:10pt=3Bfont-family:Tahoma=3B} </style> I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAgl= ue -lrsaref $LIBS" Also checked the source repository on the website= and it's there also. Can you please double check? Paul. <= br> &gt=3B Date: Wed=2C 8 Jun 2011 22:13:55 +0000 &gt=3B From: openld= ap-its(a)OpenLDAP.org &gt=3B To: the_uhu(a)hotmail.com &gt=3B Subject: Re= : (ITS#6964) ./configure bug when specifying openssl as the TLS library to = use &gt=3B &gt=3B I don't know where your configure script came from= =2C but there's nothing related &gt=3B to OpenSSL at line 19408 of the c= urrent released configure script=2C and our &gt=3B script has had logic = to detect -lrsaref since 1999. &gt=3B &gt=3B Closing this ITS. Use t= he actual configure script supplied by the OpenLDAP &gt=3B Project. = </body> </html>= --_d1f53d59-c756-486d-94a1-c6fa39a61c52_--

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by hyc＠symas.com 13 Jun '11

13 Jun '11

timo.teras(a)iki.fi wrote: > ITS#6691 seems to be same issue. > > I have a patch to fix this. > > It's available at: > http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… > > - Timo > > > Thanks for the patch, now in git master. -- -- 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#6971) Incorrect configure option in documentation
by quanah＠zimbra.com 13 Jun '11

13 Jun '11

--On Sunday, June 12, 2011 4:15 AM +0000 crhea(a)mayo.edu wrote: > Full_Name: Cris Rhea > Version: 2.4.25 > OS: Linux/CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.176.151.29) > > > http://www.openldap.org/doc/admin24/install.html#TCP%20Wrappers > > Sections 4.2.6 and 4.3 mention using "--with-wrappers" to enable TCP > Wrappers. This > option does not cause "configure" to fail, but instead, silently does > nothing. > > The correct option is "--enable-wrappers". > > This is also a minor security bug as people might think their systems have > TCP Wrapper restrictions, but unless someone tests it, they won't realize > it isn't working. > Thanks for the report, this has been fixed in the git master. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6972) [PATCH] Autogroup double-free of LDAPURLDesc *lud in autogroup_add_group when the URL contains a filter with >1 attribute.
by gerry＠everythingsucks.co.uk 13 Jun '11

13 Jun '11

--001485f86174bced0304a59d35e3 Content-Type: text/plain; charset=ISO-8859-1 In further testing this patch requires modification, I'll follow up shortly with a fixed up version. G --001485f86174bced0304a59d35e3 Content-Type: text/html; charset=ISO-8859-1 In further testing this patch requires modification, I'll follow up shortly with a fixed up version. G --001485f86174bced0304a59d35e3--

1 0

Re: (ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
by gerry＠everythingsucks.co.uk 13 Jun '11

13 Jun '11

--00163628477eca7fed04a59d338b Content-Type: text/plain; charset=ISO-8859-1 In further testing in our environment we've found this patch to be ineffective. We're seeing lockups consistently when changing other attributes. I'll follow up with more details and some traces shortly (miight try with tip first though :0) G --00163628477eca7fed04a59d338b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In further testing in our environment we've found this patch to be inef= fective. We're seeing lockups consistently when changing other a= ttributes. I'll follow up with more details and some traces shor= tly (miight try with tip first though :0) G --00163628477eca7fed04a59d338b--

1 0

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by timo.teras＠iki.fi 13 Jun '11

13 Jun '11

ITS#6657 seems to be same issue. I have a patch to fix this. It's available at: http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… - Timo

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by timo.teras＠iki.fi 13 Jun '11

13 Jun '11

ITS#6691 seems to be same issue. I have a patch to fix this. It's available at: http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… - Timo

1 0

(ITS#6972) [PATCH] Autogroup double-free of LDAPURLDesc *lud in autogroup_add_group when the URL contains a filter with >1 attribute.
by gerry＠everythingsucks.co.uk 12 Jun '11

12 Jun '11

Full_Name: Gerry Calderhead Version: OpenLDAP 2.4.25 OS: Linux RHEL5.5 URL: http://uploading.com/files/ad3ecc7f/0001-Autogroup-double-free-of-LDAPURLDe… Submission from: (NULL) (80.238.1.135) We found this issue when we swapped from dynlist to autogroup. Dynlist happily supports pulling over multiple attributes (memberuid and member in our case). When we removed dynlist and added autogroup instead we got an immediate crash because a double-free was picked up by our C library. The code at fault is in autogroup_add_group in the case for was: "to much attributes" now: "too many (%d) attributes" where the lud was free'd then "goto cleanup" was called thus attempting to free it agan. Fix --- The bare-minimum change requried to stop the crash in this case is: File:autogroup.c Function: autogroup_add_group if ( i > 1 ) { Debug( LDAP_DEBUG_ANY, "autogroup_add_group: to much attributes specified in url <%s>\n", bv->bv_val, 0, 0); /* FIXME: error? */ ldap_free_urldesc( lud ); ch_free( agf ); + continue; } I've taken the opportunity to sense-check the other error cases here and hence made the error reporting slightly more useful and eliminated the goto. The git-format-patch, containing the fix above and the clean-up I mentioned is available here: http://uploading.com/files/ad3ecc7f/0001-Autogroup-double-free-of-LDAPURLDe… sha1sum 313f55d01f37a48c5c29ea5232e6343039e6e956 0001-Autogroup-double-free-of-LDAPURLDesc-lud-in-autogrou.patch Public Domain Notice -------------------- I, Gerry Calderhead, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#6971) Incorrect configure option in documentation
by crhea＠mayo.edu 11 Jun '11

11 Jun '11

Full_Name: Cris Rhea Version: 2.4.25 OS: Linux/CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.176.151.29) http://www.openldap.org/doc/admin24/install.html#TCP%20Wrappers Sections 4.2.6 and 4.3 mention using "--with-wrappers" to enable TCP Wrappers. This option does not cause "configure" to fail, but instead, silently does nothing. The correct option is "--enable-wrappers". This is also a minor security bug as people might think their systems have TCP Wrapper restrictions, but unless someone tests it, they won't realize it isn't working.

1 0

Re: (ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
by gerry＠everythingsucks.co.uk 11 Jun '11

11 Jun '11

--001485f8123ed53b6404a5759323 Content-Type: text/plain; charset=ISO-8859-1 Note the "Analysis" section is a copy/paste of the comment from the code. When it says "this response function" it means the function: autogroup_response. G On 11 June 2011 21:24, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6970. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6970) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6970) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6970 > > Please remember to retain your issue tracking number (ITS#6970) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --001485f8123ed53b6404a5759323 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note the "Analysis" section is a copy/paste of the comment from t= he code. When it says "this response function" it means the fu= nction: autogroup_response. G <div class=3D"gmail_quote">On 11 Ju= ne 2011 21:24, <<a href=3D"mailto:openldap-its@openld= ap.org">openldap-its(a)openldap.org</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. =A0Your report has been assigned the tracking number ITS#6970. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. =A0They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. =A0Note that any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#6970) in the subject will automatically be attached to the issue report. =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a>?subject=3D(ITS#6970) You may follow the progress of this report by loading the following URL in a web browser: =A0 =A0<a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D6970" tar= get=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D6970</a> Please remember to retain your issue tracking number (ITS#6970) on any further messages you send to us regarding this report. =A0If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =A0 =A0 =A0 =A0<a href=3D"http://www.OpenLDAP.org/support/" target=3D"_bla= nk">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> --001485f8123ed53b6404a5759323--

1 0

(ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
by gerry＠everythingsucks.co.uk 11 Jun '11

11 Jun '11

Full_Name: Gerry Calderhead Version: OpenLDAP 2.4.25 OS: Linux RHEL5.5 URL: http://uploading.com/files/529d29ce/0001-MemberOf-AutoGroup-together-can-le… Submission from: (NULL) (80.238.1.135) What we're trying to do ----------------------- We are using OpenLDAP + GOsa to manage users who have access to an extranet. There are a set of tools on the extranet, let's call then VCS, Bugs, Wiki. The extranet is accessibly by third-parties. We want to delegate some admin to staff in the third parties. The structure we want to use is: Multiple organisations Each organisation has a group per tool, e.g. VCS_access, Bugs_Access, Wiki_Access. Organisation admins can add people to their own groups. We then want to aggregate all people with access to those tools into some top level groups, e.g. all_VCS_access = org1.VCS_access + org2.VCS_access all_Bugs_access = org1.Bugs_access + org2.Bugs_access all_Wiki_access = org1.Wiki_access + org2.Wiki_access It's important to us that when people are added/removed to the organisational groups that the group 'member' attributes and the user's 'memberof' attributes are correct and consistent as these for the basis for our access management. Observed Problem ----------------- If you add a user to a monitored group they are consistently added to the target group. You can now search for them using a memberof filter. If you then remove the user from a monitored group they are consistently removed from the target group. However if you then search for members of the target group using a memberOf filter the removed users always show up. 100% reproducible in our environment. Analysis -------- When using bother AutoGroup + MemberOf the "memberof" attributes are not always deleted when users are removed from a group. The approach this overlay takes to updating the target members list, when a member of a monitored list is removed, is to basically clear the membership and re-populate based on a search. Generally the Autogroup Entry requiring a refresh will be flagged in autogroup_modify_entry function. Within this response function we will then spot these flagged refreshes and will perform the deletes and searches to re-polulate the groups. So far, so simple. However, this response function is not necessarily executing in response context of the original modification (say of a "member") but could be in response to a different modification, specifically the addition of a "memberOf" attribute. i.e. it behaves asynchronously - refreshing the group sometime after the initial change. This is a problem when you wish to use MemberOf and AutoGroup together. 1. Admin removes a "member" of a group 2. AutoGroup spots the removal from a trigger group and flags a refresh on the AutoGroup Entry for the target group. 3. MemberOf overlay's _modify function is called, spots the removal of the "member" and updates the "memberOf" attribute of the trigger group. 4. This response function is called in the context of "memberOf" update 5. We spot the flag on the AGE, and delete all "member"s from the target and initiate searches to re-populate. 6. The MemberOf overlay's _modify function is called in response to the "member" changes in the target group (5). 8. MemberOf's _modify function is guarded against recursion, and exits immediately without removing the "memberof" attributes from the users in the target group. 9. When the search completes all remaining "member"'s will be re-added to the target group. The users will have their "memberOf"'s updated but the chance to remove the dead "memberOf"'s is gone. These will now linger around in the DB. So, the simplest solution I can think of is that we do not make any changes in the context of a modification that may have originated from the MemberOf overlay and instead wait on the next opportunity to trigger the refreshes. In reality if the trigger for the refresh was a "member" change then the refresh will happen during the course of the corresponding _response's - just not on any which modify "memberof". Fix ---- Add the following lines at the start of autogroup_response() if ( op->o_tag == LDAP_REQ_MODIFY ) { Modifications *mz; for ( mz = op->orm_modlist; mz; mz = mz->sml_next ) { if ( mz->sml_mod.sm_desc == agi->agi_memberof_ad ) { Debug(LDAP_DEBUG_TRACE,"==> autogroup_response in context of 'memberof' modification, do nothing!\n", 0, 0, 0); return SLAP_CB_CONTINUE; } } } Full git-format-patch present at URL specified. sha1sum 0001-MemberOf-AutoGroup-together-can-leave-stale-memberof.patch 76c2cf268fff37c0cd744e7b3cfd0afa63d9e991 0001-MemberOf-AutoGroup-together-can-leave-stale-memberof.patch Public Domain Notice -------------------- I, Gerry Calderhead, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com 10 Jun '11

10 Jun '11

> A patch to avoid this particular crash is now in git master. However, it's still not clear to me why it occurred. Can you get this info from gdb: > frame 1 > print *ss Thanks Howard, here is the info you requested: (gdb) bt #0 test_filter (op=0x40fff7f0, e=0x2aab116ab068, f=0x0) at filterentry.c:69 #1 0x00000000004db315 in syncprov_matchops (op=0x410001b0, opc=0xb096e0, saveit=1) at syncprov.c:1314 #2 0x00000000004db6b5 in syncprov_op_mod (op=0x410001b0, rs=<value optimized out>) at syncprov.c:2124 #3 0x000000000047e62a in overlay_op_walk (op=0x410001b0, rs=0x40ffffc0, which=op_modify, oi=0x8d7ab0, on=0x8dc4f0) at backover.c:659 #4 0x000000000047ec07 in over_op_func (op=0x410001b0, rs=0x40ffffc0, which=op_modify) at backover.c:721 #5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74d0, op=0x410001b0, syncCookie=0x41000b20) at syncrepl.c:3292 #6 0x0000000000478462 in do_syncrep2 (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1097 #7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1455 #8 0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84daf0) at tpool.c:685 #9 0x000000301b20673d in start_thread (arg=<value optimized out>) at pthread_create.c:301 #10 0x000000301aad44bd in clone () from /lib64/libc.so.6 (gdb) frame 1 #1 0x00000000004db315 in syncprov_matchops (op=0x410001b0, opc=0xb096e0, saveit=1) at syncprov.c:1314 1314 rc = test_filter( &op2, e, op2.ors_filter ); (gdb) print *ss $1 = {s_next = 0x2aab502177f0, s_base = {bv_len = 16, bv_val = 0x2aab730920e0 "dc=test12,dc=net"}, s_eid = 1, s_op = 0x230ea90, s_rid = 1, s_sid = -1, s_filterstr = {bv_len = 15, bv_val = 0x230f7d0 "(objectClass=*)"}, s_flags = 1, s_inuse = 1, s_res = 0x2aababca90f0, s_restail = 0x2aabc320d920, s_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}

1 0

(ITS#6969) Need option to show which TLS library is in use
by hyc＠OpenLDAP.org 10 Jun '11

10 Jun '11

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc Now that OpenSSL is not the only TLS library that we support, app developers need a way to check which library is in use. libldap has the info, but due to an oversight it was not exposed. The LDAP_OPT_X_TLS_PACKAGE option has been added to retrieve the TLS implementation name. Currently it may be "OpenSSL", "GnuTLS", or "MozNSS".

1 0

Re: (ITS#6968) Glue objectclass created during Grouper provisioning
by hyc＠symas.com 10 Jun '11

10 Jun '11

Mark.Cairney(a)ed.ac.uk wrote: > Full_Name: Mark Cairney > Version: 2.4.25 > OS: RHEL 5.5 x64 > URL: ftp://ftp.ed.ac.uk/incoming/Mark-Cairney-110610.zip > Submission from: (NULL) (129.215.200.77) > > > During provisioning using Grouper (http://www.internet2.edu/grouper) to populate > a tree of ou and posixGroup objects it looks like the request to create a child > OU is being issued and granted. > This results in the creation of a "ghost" parent OU with the glue objectClass as > documented but syncrepl then constantly tries and fails to provision the ghost > OU to the other servers (as shown in alderlog.txt). Your ftp server is demanding authentication, can't download your file. > My cn=config is listed in cnconfig.txt for reference > > The issue can be reproduced by running Grouper's LDAP provisioner with Grouper > configured to produce a "bushy" structure and it may also be reproduceable if > provisioning via a suitable large LDIF file (grouper.ldif). Sorry, I'm not going to install grouper to test this bug. Please provide scripts to generate data that will reproduce the bug, and please do not use any 3rd party schemas in the data, that just makes it harder to setup a test environment. -- -- 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#6968) Glue objectclass created during Grouper provisioning
by Mark.Cairney＠ed.ac.uk 10 Jun '11

10 Jun '11

Full_Name: Mark Cairney Version: 2.4.25 OS: RHEL 5.5 x64 URL: ftp://ftp.ed.ac.uk/incoming/Mark-Cairney-110610.zip Submission from: (NULL) (129.215.200.77) During provisioning using Grouper (http://www.internet2.edu/grouper) to populate a tree of ou and posixGroup objects it looks like the request to create a child OU is being issued and granted. This results in the creation of a "ghost" parent OU with the glue objectClass as documented but syncrepl then constantly tries and fails to provision the ghost OU to the other servers (as shown in alderlog.txt). My cn=config is listed in cnconfig.txt for reference The issue can be reproduced by running Grouper's LDAP provisioner with Grouper configured to produce a "bushy" structure and it may also be reproduceable if provisioning via a suitable large LDIF file (grouper.ldif).

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com 10 Jun '11

10 Jun '11

Daniel Pluta wrote: > Howard Chu wrote: >> daniel at pluta.biz wrote: >>> Please also have a look into the might be related patch, submitted in >>> ITS#6912 which addresses normalization of auth(c|z)Id of the form >>> "u:xxx" in general. Thank you very much. >> >> I see no bug here. The backslash was properly escaped, using the normal >> escaping rules for LDAP DNs. >> > > Yeah, you are right, but ... ;-) > ... I'm perhaps too. So please let me try to explain: > > The backslash is syntactically correct escaped (under the assumtion that > the string is indeed a "LDAP DN"). > > In my opinion authz-regexp (a slapd-config-statement string) completely > or partly does not always represent a "LDAP DN". It's quite often more > or less a combination of > > LDAP URI + optional regex + its optional expansions > > which probably should not be treated in general (especially in regard to > normalization) like a LDAP DN. > > This has led me to the submitted patch in ITS#6912 where I assume that > in contrast to authDN-normalization, the normalization of authIDs > (u:xxxx) in general is probably quite problematic, too... > > I'm aware that LDAP DNs need to be normalized in general, but I do not > understand why authcIDs or authz-regexp-expansions should need to be > normalized in general, too. > The authz-regexp expansion does not "need" to be normalized. But it is fed a DN, and that DN is normalized before any further processing, so if you want to match it, you must use the proper normalized string in your regexp: use "\\5C" instead of "\\". Next time send your usage questions to the -technical mailing list. This ITS is closed. -- -- 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#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 10 Jun '11

10 Jun '11

Howard Chu wrote: > daniel at pluta.biz wrote: >> Please also have a look into the might be related patch, submitted in >> ITS#6912 which addresses normalization of auth(c|z)Id of the form >> "u:xxx" in general. Thank you very much. > > I see no bug here. The backslash was properly escaped, using the normal > escaping rules for LDAP DNs. > Yeah, you are right, but ... ;-) ... I'm perhaps too. So please let me try to explain: The backslash is syntactically correct escaped (under the assumtion that the string is indeed a "LDAP DN"). In my opinion authz-regexp (a slapd-config-statement string) completely or partly does not always represent a "LDAP DN". It's quite often more or less a combination of LDAP URI + optional regex + its optional expansions which probably should not be treated in general (especially in regard to normalization) like a LDAP DN. This has led me to the submitted patch in ITS#6912 where I assume that in contrast to authDN-normalization, the normalization of authIDs (u:xxxx) in general is probably quite problematic, too... I'm aware that LDAP DNs need to be normalized in general, but I do not understand why authcIDs or authz-regexp-expansions should need to be normalized in general, too.

1 0

Re: (ITS#6892) Segfault in Syncprov overlay
by hyc＠symas.com 10 Jun '11

10 Jun '11

ghola(a)rebelbase.com wrote: > Full_Name: Duncan Idaho > Version: 2.4.25 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.10.36.147) > > > In my configuration slapd segfaults within a few hours repeatably when a NULL > value is somehow passed as a filter to test_filter in the syncprov overlay. > > I'm running "threads 64" as I have 62 consumers connecting and this was required > to prevent unrelated searches from timing out when all the consumers connect at > once. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x59832940 (LWP 2042)] > test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 > 69 if ( f->f_choice& SLAPD_FILTER_UNDEFINED ) { > (gdb) bt > #0 test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 > #1 0x00000000004db315 in syncprov_matchops (op=0x59831130, opc=0xbc91750, > saveit=1) at syncprov.c:1314 > #2 0x00000000004db6b5 in syncprov_op_mod (op=0x59831130, rs=<value optimized > out>) at syncprov.c:2124 > #3 0x000000000047e62a in overlay_op_walk (op=0x59831130, rs=0x59830f40, > which=op_modify, oi=0x8d7b50, on=0x8dc540) at backover.c:659 > #4 0x000000000047ec07 in over_op_func (op=0x59831130, rs=0x59830f40, > which=op_modify) at backover.c:721 > #5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74e0, op=0x59831130, > syncCookie=0x59831aa0) at syncrepl.c:3292 > #6 0x0000000000479d0d in do_syncrep2 (ctx=<value optimized out>, arg=<value > optimized out>) at syncrepl.c:959 > #7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at > syncrepl.c:1455 > #8 0x000000000041f7aa in connection_read_thread (ctx=0x59831d70, argv=<value > optimized out>) at connection.c:1251 > #9 0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84de50) at > tpool.c:685 > #10 0x000000301b20673d in start_thread (arg=<value optimized out>) at > pthread_create.c:301 > #11 0x000000301aad44bd in clone () from /lib64/libc.so.6 > > Let me know if I can provide more info. A patch to avoid this particular crash is now in git master. However, it's still not clear to me why it occurred. Can you get this info from gdb: frame 1 print *ss -- -- 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#6967) bug when migrating to cn=config with mixed-case schema names
by hyc＠symas.com 10 Jun '11

10 Jun '11

seth(a)energysec.org wrote: > Full_Name: Seth B. > Version: 2.4.25 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.37.253.46) > > > I moved from slapd.conf to cn=config using options -F and -f (forgot the exact > command but I think it was slapadd). I had a schema called EnergySec.ldif that > was migrated. It showed up as > /usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}EnergySec.ldif > following the conversion. > > However, when I tried modifying the schema using ADS and then ldapmodify, I > would get a error 32: No such object. With slapd in foreground mode, I found > that it was trying to access the lower-case version of the file: > > ldif_read_file: no entry file > "/usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}energysec.ldif" > > Since UNIX is case-sensitive, this obviously failed (the import kept the case as > EnergySec.ldif). > > I fixed it by manually renaming the ldif file to lower case and changing the dn > and cn inside the file. That was pretty hairy and I hope I didn't break anything > else but it semes to work. Thanks for the report, this is now fixed in git master. -- -- 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#6967) bug when migrating to cn=config with mixed-case schema names
by seth＠energysec.org 09 Jun '11

09 Jun '11

Full_Name: Seth B. Version: 2.4.25 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.37.253.46) I moved from slapd.conf to cn=config using options -F and -f (forgot the exact command but I think it was slapadd). I had a schema called EnergySec.ldif that was migrated. It showed up as /usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}EnergySec.ldif following the conversion. However, when I tried modifying the schema using ADS and then ldapmodify, I would get a error 32: No such object. With slapd in foreground mode, I found that it was trying to access the lower-case version of the file: ldif_read_file: no entry file "/usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}energysec.ldif" Since UNIX is case-sensitive, this obviously failed (the import kept the case as EnergySec.ldif). I fixed it by manually renaming the ldif file to lower case and changing the dn and cn inside the file. That was pretty hairy and I hope I didn't break anything else but it semes to work.

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com 09 Jun '11

09 Jun '11

daniel(a)pluta.biz wrote: > Please also have a look into the might be related patch, submitted in > ITS#6912 which addresses normalization of auth(c|z)Id of the form > "u:xxx" in general. Thank you very much. I see no bug here. The backslash was properly escaped, using the normal escaping rules for LDAP DNs. -- -- 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#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 09 Jun '11

09 Jun '11

Please also have a look into the might be related patch, submitted in ITS#6912 which addresses normalization of auth(c|z)Id of the form "u:xxx" in general. Thank you very much.

1 0

Re: (ITS#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠zimbra.com 09 Jun '11

09 Jun '11

--On Thursday, June 09, 2011 10:19 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > The admin guide refers to "Start TLS" in multiple locations instead of > "StartTLS", which leads to confusion among end users, and makes searching > for the startTLS pieces a pain. I will fix shortly. > I will mark this as invalid, as this is how it is described in all the RFCs as well (Start TLS). --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com 09 Jun '11

09 Jun '11

mark.cave-ayland(a)siriusit.co.uk wrote: > Full_Name: Mark Cave-Ayland > Version: 2.4.23 > OS: Linux/Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.187.123.11) > > > Hi all, > > We have an issue on one of our production systems whereby openldap is not > enforcing the ACLs on a back-perl subordinate database. Keep in mind, this is back-perl's documented behavior. >>> ACCESS CONTROL The perl backend does not honor any of the access control semantics described in slapd.access(5); all access control is delegated to the underlying PERL scripting. Only read (=r) access to the entry pseudo- attribute and to the other attribute values of the entries returned by the search operation is honored, which is performed by the frontend. <<< Treating this as an enhancement request. > In this particular system, the membership of certain groups stored within LDAP > is determined by some customised logic in a Perl module which dynamically > generates LDAP objects with posixGroup/groupOfNames entries conditionally based > upon the values of existing LDAP attributes within the tree. However, since > these internal LDAP attribute lookups can be quite slow, we wish to hide them > from all but a small minority of bind DNs. Unfortunately what we are finding is > that the back-perl module is not respecting the ACLs in slapd.conf. > > The following files can be used to reproduce this issue with openldap 2.4.23: > > http://pastebin.siriusit.co.uk/perlacl/slapd.conf > http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif > http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm > > The password for both the "cn=admin,dc=my-domain,dc=com" and the > "cn=restricted,dc=my-domain,dc=com" DNs is secret. > > The ACLs in the above slapd.conf look like this: > > access to dn.subtree="ou=perl,dc=my-domain,dc=com" > by dn="cn=admin,dc=my-domain,dc=com" read > by dn="cn=restricted,dc=my-domain,dc=com" none > > access to dn.subtree="ou=hidden,dc=my-domain,dc=com" > by dn="cn=admin,dc=my-domain,dc=com" read > by dn="cn=restricted,dc=my-domain,dc=com" none > > access to * > by dn="cn=admin,dc=my-domain,dc=com" write > by dn="cn=restricted,dc=my-domain,dc=com" read > by * auth > > Using these ACLs, I would expect that cn=admin should be able to read the whole > directory, whereas cn=restricted should not be able to see either the > "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com" > DN subtree. > > However, performing an LDAP search binding as cn=restricted gives the following > output: > > build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D > 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW > Enter LDAP Password: > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: real > > dn: ou=realtest1,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest1 > > dn: ou=realtest2,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest2 > > dn: ou=realtest3,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest3 > > dn: ou=realtest4,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest4 > > dn: ou=realtest5,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest5 > > dn: cn=restricted,dc=my-domain,dc=com > objectClass: simpleSecurityObject > objectClass: organizationalRole > cn: restricted > description: restricted user > userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 > > dn: cn=admin,dc=my-domain,dc=com > objectClass: simpleSecurityObject > objectClass: organizationalRole > cn:: YWRtaW4g > description: admin user > userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 > > dn: ou=perltest5,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest5 > > dn: ou=perltest4,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest4 > > dn: ou=perltest3,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest3 > > dn: ou=perltest2,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest2 > > dn: ou=perltest1,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest1 > > > In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden > from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree > is not. > > -- -- 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#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠OpenLDAP.org 09 Jun '11

09 Jun '11

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The admin guide refers to "Start TLS" in multiple locations instead of "StartTLS", which leads to confusion among end users, and makes searching for the startTLS pieces a pain. I will fix shortly.

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com 09 Jun '11

09 Jun '11

mark.cave-ayland(a)siriusit.co.uk wrote: > On 09/06/11 00:21, Quanah Gibson-Mount wrote: > >>> An update on this bug report: with a modified slapd.conf and a small >>> patch to the back-perl module, I can use the ACL mask to ensure that the >>> perl search function doesn't get invoked if disallowed by the ACLs. >>> >>> The patch works by creating a "fake" empty entry whose DN is the base of >>> the search, and then passing this entry into access_allowed() using code >>> borrowed from one of the other backends to either deny or allow access. >>> >>> http://pastebin.siriusit.co.uk/perlacl/slapd2.conf >>> http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch >> >> These are not accessible. > > Hi Quanah, > > Ah yes indeed - that server was decommissioned last month. I've since > reinstated the files from a backup onto a new server and updated DNS to > point to it. Can you verify that you can now download them? Thanks, got it now. The patch leaks memory. I'll commit a fixed version of it shortly. -- -- 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#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by mark.cave-ayland＠siriusit.co.uk 09 Jun '11

09 Jun '11

On 09/06/11 00:21, Quanah Gibson-Mount wrote: >> An update on this bug report: with a modified slapd.conf and a small >> patch to the back-perl module, I can use the ACL mask to ensure that the >> perl search function doesn't get invoked if disallowed by the ACLs. >> >> The patch works by creating a "fake" empty entry whose DN is the base of >> the search, and then passing this entry into access_allowed() using code >> borrowed from one of the other backends to either deny or allow access. >> >> http://pastebin.siriusit.co.uk/perlacl/slapd2.conf >> http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch > > These are not accessible. Hi Quanah, Ah yes indeed - that server was decommissioned last month. I've since reinstated the files from a backup onto a new server and updated DNS to point to it. Can you verify that you can now download them? Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

(ITS#6965) Ldap ld210_en for Mdaemon ver 11.0.1-urgent
by elena.morozova＠softline.ru 09 Jun '11

09 Jun '11

Full_Name: Elena Morozova Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.141.102.2) Hello, Earlier our client used Ldap ld210_en for Mdaemon ver 11.0.1. What can you advise to use instead of Ldap ld210_en for Mdaemon ver 11.0.1? Thank you.

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com 09 Jun '11

09 Jun '11

Andrew Findlay wrote: > On Tue, Feb 15, 2011 at 05:02:52AM -0800, Howard Chu wrote: > >>> slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema >>> fragments for pwdPolicySubentry and pwdAccountLockedTime. >> >> That's how they were defined in the IETF Draft. The schema fragments >> in the manpage were copied directly from the spec. The fact that the >> current implementation deviates from the spec is just out of >> necessity to make things work at all in our present code base. > > Certainly the use of pwdPolicySubentry differs from the > intention of the draft (which I believe was intending to use > real X.500-style subentries). > > The case of pwdAccountLockedTime is arguable. > draft-behera-ldap-password-policy-xx.txt says: > > This attribute holds the time that the user's account was locked. A > locked account means that the password may no longer be used to > authenticate. A 000001010000Z value means that the account has been > locked permanently, and that only a password administrator can unlock > the account. > > Unfortunately it says nothing about *how* a password > administrator should do that when the attribute is marked > NO-USER-MODIFICATION. I would argue that this is a > deficiency in the draft, and that the current OpenLDAP > behaviour is more useful. > >> Things will not always work this way... > > Indeed, but I would prefer the manpages to reflect the > reality of the current release! I note that in ppolicy.c we have: { "( 1.3.6.1.4.1.42.2.27.8.1.17 " "NAME ( 'pwdAccountLockedTime' ) " "DESC 'The time an user account was locked' " "EQUALITY generalizedTimeMatch " "ORDERING generalizedTimeOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " "SINGLE-VALUE " #if 0 /* Not until Relax control is released */ "NO-USER-MODIFICATION " #endif "USAGE directoryOperation )", We have in fact released support for the Relax control, so it's probably time to unifdef these bits and go back to the documented behavior. -- -- 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: [PATCH] More for ITS#6872
by hyc＠symas.com 09 Jun '11

09 Jun '11

cmikk(a)qwest.net wrote: > [Note: The previous patch did not fix the problem when > the consumer's access was restricted to the replicated > subtree. This patch fixes that.] Both applied to git master, thanks. > > Perform the internal FIND_CSN search based at the backend's suffix with the > privileges of the backend's root DN. > --- > servers/slapd/overlays/syncprov.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c > index 0c148f9..a058e19 100644 > --- a/servers/slapd/overlays/syncprov.c > +++ b/servers/slapd/overlays/syncprov.c > @@ -661,6 +661,8 @@ again: > if ( BER_BVISEMPTY(&cf.f_av_value )) { > cf.f_av_value = *csn; > } > + fop.o_dn = op->o_bd->be_rootdn; > + fop.o_ndn = op->o_bd->be_rootndn; > fop.o_req_dn = op->o_bd->be_suffix[0]; > fop.o_req_ndn = op->o_bd->be_nsuffix[0]; > /* Look for exact match the first time */ -- -- 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#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com 08 Jun '11

08 Jun '11

hyc(a)symas.com wrote: > bcolston(a)xtec.com wrote: >> Full_Name: Barry Colston >> Version: 2.4.23 >> OS: Fedora 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.255.208.200) > > I'm looking at your test case now. One thing to note, serverIDs must all be > non-zero in a multi-master configuration. serverID == 0 is only valid in > single-master replication. > >> When a "Refresh Present" phase is performed at a multi-master consumer, objects >> that were deleted at the provider >> while the consumer was down are not deleted from the multi-master consumer (if >> the provider is brought down and back up after the consumer is down). This >> problem can be duplicated as follows: >> 1. Start provider >> 2. Start consumer, which is configured as a multi-master server >> 3. Add 10 records to the provider and wait until the records are replicated to >> the multi-master consumer >> 4. Stop the consumer >> 5. Delete 3 of the records that were added to the provider >> 6. Stop the provider >> 7. Start the provider >> 8. Start the consumer >> 9. After giving the consumer time to perform the refresh present phase, the 3 >> records that were deleted at the provider while the consumer was down >> are still present on the consumer and were not deleted during the refresh >> present phase >> >> Note: the consumer database must have a contextCSN attribute value present for >> itself (e.g., there should be 2 contextCSN attribute values >> present in the consumer database, one for the provider (in my configuration, >> this is serverID 000), and one value for the consumer >> (in my configuration, this is serverID 001). An example of the contextCSN >> values follows: I see. This configuration is not supported. "Multi-Master" requires the servers to be full peers. In your configuration, you have a dedicated provider, it never pulls changes from the consumer, while your consumer is pulling from the provider and accepting local changes. Since the consumer has changes that the provider doesn't know about, the sync protocol is broken. The consumer cannot conclusively state that all entries the provider doesn't know about must be deleted, since some of those entries may have legitimately been created on the consumer, so it cannot execute the delete-nonpresent step. Closing this ITS. >> dn: dc=authentx >> objectClass: top >> entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f >> contextCSN: 20101012154030.379053Z#000000#000#000000 >> contextCSN: 20101012141508.956053Z#000000#001#000000 >> >> OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). >> >> Consumer log file from -d sync logging option: >> @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ >> Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd >> slapd starting >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT >> do_syncrep2: rid=001 >> cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 >> slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 >> slap_graduate_commit_csn: removing 0x1841b18 >> 20101012180219.072053Z#000000#000#000000 >> daemon: shutdown requested and initiated. >> slapd shutdown: waiting for 1 operations/tasks to finish >> slapd stopped. >> >> Provider slapd.conf file: >> # >> include /usr/local/etc/openldap/schema/core.schema >> include /usr/local/etc/openldap/schema/cosine.schema >> include /usr/local/etc/openldap/schema/inetorgperson.schema >> include /usr/local/etc/openldap/schema/nis.schema >> >> include /usr/local/etc/openldap/schema/authentx.schema >> >> pidfile /usr/local/var/slapd.sync1.pid >> argsfile /usr/local/var/slapd.sync1.args >> >> allow bind_v2 >> >> threads 32 >> >> #loglevel 416 >> password-hash {SSHA} >> >> serverID 000 >> >> database bdb >> suffix "dc=authentx" >> rootdn "cn=xroot,dc=authentx" >> rootpw SECRET >> directory /authentx/db/ldap/authentx-sync1 >> >> overlay syncprov >> syncprov-checkpoint 100 15 >> syncprov-sessionlog 150000 >> >> # checkpoint<kbytes> <min> >> checkpoint 128 20 >> >> #index for the objectclass >> index objectClass eq,pres >> index cid,eid,pid eq,pres >> index gcoid eq,pres >> index sysid,certid eq,pres >> index imageid,bioid eq,pres >> index addrid,emplid eq,pres >> index acid,apid,aeid eq,pres >> index acpid,agpid eq,pres >> index deviceid eq,pres >> index qid eq,pres >> index scid eq,pres >> index docid eq,pres >> index procid eq,pres >> index prochandlerid eq,pres >> index ounit eq,pres >> index credentials eq,pres >> index entities eq,pres >> index permissions eq,pres >> index region eq,pres >> index aliasedObjectName eq,pres >> index proctype eq,pres >> index procname eq,pres >> index status eq,pres >> index upi,ediident eq,pres >> index xsync eq,pres >> index role,xrole eq,pres >> index eroid eq,pres >> index esfunction eq,pres >> index nippsector eq,pres >> index ercog,ercoop eq,pres >> index eropron eq,pres >> index xsyncid eq,pres >> index stockid eq,pres >> index stocktypecode eq,pres >> index lotserialin eq,pres >> index lotserialout eq,pres >> index entryCSN,entryUUID eq >> index incl eq,pres >> >> cachesize 10000 >> dncachesize 20000 >> idlcachesize 1000 >> >> sizelimit 500000 >> timelimit 36000 >> include /usr/local/etc/openldap/acl.authentx >> >> database monitor >> >> Consumer slapd.conf file: >> # >> include /usr/local/etc/openldap/schema/core.schema >> include /usr/local/etc/openldap/schema/cosine.schema >> include /usr/local/etc/openldap/schema/inetorgperson.schema >> include /usr/local/etc/openldap/schema/nis.schema >> >> include /usr/local/etc/openldap/schema/authentx.schema >> >> pidfile /usr/local/var/slapd.sync2.pid >> argsfile /usr/local/var/slapd.sync2.args >> >> allow bind_v2 >> >> threads 32 >> >> #loglevel 416 >> password-hash {SSHA} >> >> serverID 001 >> >> database bdb >> suffix "dc=authentx" >> rootdn "cn=xroot,dc=authentx" >> rootpw SECRET >> directory /authentx/db/ldap/authentx-sync2 >> >> overlay syncprov >> syncprov-checkpoint 100 15 >> syncprov-sessionlog 5000 >> >> # SLAVE server replication section >> syncrepl rid=001 >> provider=ldap://localhost:3891 >> type=refreshAndPersist >> retry="30 60 60 +" >> searchbase="dc=authentx" >> scope=sub >> schemachecking=off >> bindmethod=simple >> binddn="cn=xroot,dc=authentx" >> credentials="SECRET" >> >> mirrormode on >> >> # checkpoint<kbytes> <min> >> checkpoint 128 20 >> >> #index for the objectclass >> index objectClass eq,pres >> index cid,eid,pid eq,pres >> index gcoid eq,pres >> index sysid,certid eq,pres >> index imageid,bioid eq,pres >> index addrid,emplid eq,pres >> index acid,apid,aeid eq,pres >> index acpid,agpid eq,pres >> index deviceid eq,pres >> index qid eq,pres >> index scid eq,pres >> index docid eq,pres >> index procid eq,pres >> index prochandlerid eq,pres >> index ounit eq,pres >> index credentials eq,pres >> index entities eq,pres >> index permissions eq,pres >> index region eq,pres >> index aliasedObjectName eq,pres >> index proctype eq,pres >> index procname eq,pres >> index status eq,pres >> index upi,ediident eq,pres >> index xsync eq,pres >> index role,xrole eq,pres >> index eroid eq,pres >> index esfunction eq,pres >> index nippsector eq,pres >> index ercog,ercoop eq,pres >> index eropron eq,pres >> index xsyncid eq,pres >> index stockid eq,pres >> index stocktypecode eq,pres >> index lotserialin eq,pres >> index lotserialout eq,pres >> index entryCSN,entryUUID eq >> index incl eq,pres >> >> cachesize 10000 >> dncachesize 20000 >> idlcachesize 1000 >> >> sizelimit 100000 >> timelimit 36000 >> # the authentx database access control directives >> include /usr/local/etc/openldap/acl.authentx >> >> database monitor >> >> > > -- -- 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#6880) SECURITY: ldap_free_urllist segfault
by Howard Chu 08 Jun '11

08 Jun '11

> Full_Name: Marcus Rottensteiner > Version: 2.4.24 > OS: gentoo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (188.20.205.34) > > > running a php program, openldap 2.4.24 has a problem in libldap_r-2.4.so.2 > > in conjunction with php 5.3 (tested 5.3.5 , 5.3.6) ? > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff39bcb4b in ldap_free_urllist () from /usr//lib/libldap-2.4.so.2 > (gdb) backtrace > #0 0x00007ffff39bcb4b in ldap_free_urllist () from /usr//lib/libldap-2.4.so.2 > #1 0x00007ffff1a60c1b in ?? () from /usr/lib64/libldap_r-2.4.so.2 > #2 0x00007ffff1a4680e in ?? () from /usr/lib64/libldap_r-2.4.so.2 > #3 0x0000000000000030 in ?? () > #4 0x0000000000000000 in ?? () > > Reverting to openldap 2.4.23 does not cause a problem ! Your trace shows that both libldap and libldap_r are present. Your PHP is built incorrectly. You cannot link both libraries into the same program; they are not compatible. Closing this ITS.

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 08 Jun '11

08 Jun '11

hyc(a)symas.com wrote: > ipuleston(a)SonicWALL.com wrote: >> The patch that I submitted above has a memory leak due not freeing "ber" > when returning error LDAP_X_CONNECTING from function > ldap_send_initial_request(). I have uploaded a new version of the patch with > this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note > the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode). > > Unfortunately the patch was made against 2.4.23 and not against HEAD. It does > not apply cleanly to current git. Patches must always be submitted against the > development code, not against released code. I've committed an alternate patch to git master. > > I'm pretty sure that this chunk can never do anything useful. > > diff -u libldap.orig/request.c libldap/request.c > --- libldap.orig/request.c 2010-06-10 10:39:48.000000000 -0700 > +++ libldap/request.c 2011-04-12 12:11:20.769166100 -0700 > @@ -446,7 +462,21 @@ > lc->lconn_server = ldap_url_dup( srv ); > } > > - lc->lconn_status = async ? LDAP_CONNST_CONNECTING : LDAP_CONNST_CONNECTED; > + if ( async ) { > +#ifdef HAVE_TLS > + void *ssl = NULL; > + ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_GET_SSL, (void *)&ssl ); > + if ( ssl ) { > + /* the connect finished and tls was started */ > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + } else > +#endif > + { > + lc->lconn_status = LDAP_CONNST_CONNECTING; > + } > + } else { > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + } > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_lock(&ld->ld_conn_mutex ); > #endif > > The connection has just been created, asynchronously, so there's no way that > the TLS layer was already started when it got here. Also, even if this was > valid, it obviously would only apply for OPT_X_TLS_HARD || ldaps, but you > haven't checked that condition here. Ultimately it appears that this test is a > no-op. > > Also, I suggest that you only check for CONNST_CONNECTING in the callers, and > do the TLS check in the check function, like this: > > +int > +ldap_int_check_async_open( LDAP *ld, LDAPConn *lc, LDAPURLDesc *srv, > ber_socket_t sd ) > +{ > + struct timeval tv = { 0 }; > + int rc; > + > + rc = ldap_int_poll( ld, sd,&tv ); > + switch ( rc ) { > + case 0: > + /* now ready to start tls */ > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + break; > + > + default: > + rc = -1; > + return rc; > + case -2: > + /* connect not completed yet */ > + ld->ld_errno = LDAP_X_CONNECTING; > + return rc; > + } > + > +#ifdef HAVE_TLS > + if ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > + !strcmp( srv->lud_scheme, "ldaps" )) { > + > + ++lc->lconn_refcnt; /* avoid premature free */ > + > + rc = ldap_int_tls_start( ld, lc, srv ); > + > + --lc->lconn_refcnt; > + } > +#endif > + return rc; > +} > -- -- 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#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com 08 Jun '11

08 Jun '11

bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.23 > OS: Fedora 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.200) I'm looking at your test case now. One thing to note, serverIDs must all be non-zero in a multi-master configuration. serverID == 0 is only valid in single-master replication. > When a "Refresh Present" phase is performed at a multi-master consumer, objects > that were deleted at the provider > while the consumer was down are not deleted from the multi-master consumer (if > the provider is brought down and back up after the consumer is down). This > problem can be duplicated as follows: > 1. Start provider > 2. Start consumer, which is configured as a multi-master server > 3. Add 10 records to the provider and wait until the records are replicated to > the multi-master consumer > 4. Stop the consumer > 5. Delete 3 of the records that were added to the provider > 6. Stop the provider > 7. Start the provider > 8. Start the consumer > 9. After giving the consumer time to perform the refresh present phase, the 3 > records that were deleted at the provider while the consumer was down > are still present on the consumer and were not deleted during the refresh > present phase > > Note: the consumer database must have a contextCSN attribute value present for > itself (e.g., there should be 2 contextCSN attribute values > present in the consumer database, one for the provider (in my configuration, > this is serverID 000), and one value for the consumer > (in my configuration, this is serverID 001). An example of the contextCSN > values follows: > > dn: dc=authentx > objectClass: top > entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f > contextCSN: 20101012154030.379053Z#000000#000#000000 > contextCSN: 20101012141508.956053Z#000000#001#000000 > > OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). > > Consumer log file from -d sync logging option: > @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ > Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd > slapd starting > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT > do_syncrep2: rid=001 > cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 > slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 > slap_graduate_commit_csn: removing 0x1841b18 > 20101012180219.072053Z#000000#000#000000 > daemon: shutdown requested and initiated. > slapd shutdown: waiting for 1 operations/tasks to finish > slapd stopped. > > Provider slapd.conf file: > # > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/nis.schema > > include /usr/local/etc/openldap/schema/authentx.schema > > pidfile /usr/local/var/slapd.sync1.pid > argsfile /usr/local/var/slapd.sync1.args > > allow bind_v2 > > threads 32 > > #loglevel 416 > password-hash {SSHA} > > serverID 000 > > database bdb > suffix "dc=authentx" > rootdn "cn=xroot,dc=authentx" > rootpw SECRET > directory /authentx/db/ldap/authentx-sync1 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 150000 > > # checkpoint<kbytes> <min> > checkpoint 128 20 > > #index for the objectclass > index objectClass eq,pres > index cid,eid,pid eq,pres > index gcoid eq,pres > index sysid,certid eq,pres > index imageid,bioid eq,pres > index addrid,emplid eq,pres > index acid,apid,aeid eq,pres > index acpid,agpid eq,pres > index deviceid eq,pres > index qid eq,pres > index scid eq,pres > index docid eq,pres > index procid eq,pres > index prochandlerid eq,pres > index ounit eq,pres > index credentials eq,pres > index entities eq,pres > index permissions eq,pres > index region eq,pres > index aliasedObjectName eq,pres > index proctype eq,pres > index procname eq,pres > index status eq,pres > index upi,ediident eq,pres > index xsync eq,pres > index role,xrole eq,pres > index eroid eq,pres > index esfunction eq,pres > index nippsector eq,pres > index ercog,ercoop eq,pres > index eropron eq,pres > index xsyncid eq,pres > index stockid eq,pres > index stocktypecode eq,pres > index lotserialin eq,pres > index lotserialout eq,pres > index entryCSN,entryUUID eq > index incl eq,pres > > cachesize 10000 > dncachesize 20000 > idlcachesize 1000 > > sizelimit 500000 > timelimit 36000 > include /usr/local/etc/openldap/acl.authentx > > database monitor > > Consumer slapd.conf file: > # > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/nis.schema > > include /usr/local/etc/openldap/schema/authentx.schema > > pidfile /usr/local/var/slapd.sync2.pid > argsfile /usr/local/var/slapd.sync2.args > > allow bind_v2 > > threads 32 > > #loglevel 416 > password-hash {SSHA} > > serverID 001 > > database bdb > suffix "dc=authentx" > rootdn "cn=xroot,dc=authentx" > rootpw SECRET > directory /authentx/db/ldap/authentx-sync2 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 5000 > > # SLAVE server replication section > syncrepl rid=001 > provider=ldap://localhost:3891 > type=refreshAndPersist > retry="30 60 60 +" > searchbase="dc=authentx" > scope=sub > schemachecking=off > bindmethod=simple > binddn="cn=xroot,dc=authentx" > credentials="SECRET" > > mirrormode on > > # checkpoint<kbytes> <min> > checkpoint 128 20 > > #index for the objectclass > index objectClass eq,pres > index cid,eid,pid eq,pres > index gcoid eq,pres > index sysid,certid eq,pres > index imageid,bioid eq,pres > index addrid,emplid eq,pres > index acid,apid,aeid eq,pres > index acpid,agpid eq,pres > index deviceid eq,pres > index qid eq,pres > index scid eq,pres > index docid eq,pres > index procid eq,pres > index prochandlerid eq,pres > index ounit eq,pres > index credentials eq,pres > index entities eq,pres > index permissions eq,pres > index region eq,pres > index aliasedObjectName eq,pres > index proctype eq,pres > index procname eq,pres > index status eq,pres > index upi,ediident eq,pres > index xsync eq,pres > index role,xrole eq,pres > index eroid eq,pres > index esfunction eq,pres > index nippsector eq,pres > index ercog,ercoop eq,pres > index eropron eq,pres > index xsyncid eq,pres > index stockid eq,pres > index stocktypecode eq,pres > index lotserialin eq,pres > index lotserialout eq,pres > index entryCSN,entryUUID eq > index incl eq,pres > > cachesize 10000 > dncachesize 20000 > idlcachesize 1000 > > sizelimit 100000 > timelimit 36000 > # the authentx database access control directives > include /usr/local/etc/openldap/acl.authentx > > database monitor > > -- -- 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#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 08 Jun '11

08 Jun '11

ipuleston(a)SonicWALL.com wrote: > The patch that I submitted above has a memory leak due not freeing "ber" when returning error LDAP_X_CONNECTING from function ldap_send_initial_request(). I have uploaded a new version of the patch with this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode). Unfortunately the patch was made against 2.4.23 and not against HEAD. It does not apply cleanly to current git. Patches must always be submitted against the development code, not against released code. I'm pretty sure that this chunk can never do anything useful. diff -u libldap.orig/request.c libldap/request.c --- libldap.orig/request.c 2010-06-10 10:39:48.000000000 -0700 +++ libldap/request.c 2011-04-12 12:11:20.769166100 -0700 @@ -446,7 +462,21 @@ lc->lconn_server = ldap_url_dup( srv ); } - lc->lconn_status = async ? LDAP_CONNST_CONNECTING : LDAP_CONNST_CONNECTED; + if ( async ) { +#ifdef HAVE_TLS + void *ssl = NULL; + ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_GET_SSL, (void *)&ssl ); + if ( ssl ) { + /* the connect finished and tls was started */ + lc->lconn_status = LDAP_CONNST_CONNECTED; + } else +#endif + { + lc->lconn_status = LDAP_CONNST_CONNECTING; + } + } else { + lc->lconn_status = LDAP_CONNST_CONNECTED; + } #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex ); #endif The connection has just been created, asynchronously, so there's no way that the TLS layer was already started when it got here. Also, even if this was valid, it obviously would only apply for OPT_X_TLS_HARD || ldaps, but you haven't checked that condition here. Ultimately it appears that this test is a no-op. Also, I suggest that you only check for CONNST_CONNECTING in the callers, and do the TLS check in the check function, like this: +int +ldap_int_check_async_open( LDAP *ld, LDAPConn *lc, LDAPURLDesc *srv, ber_socket_t sd ) +{ + struct timeval tv = { 0 }; + int rc; + + rc = ldap_int_poll( ld, sd, &tv ); + switch ( rc ) { + case 0: + /* now ready to start tls */ + lc->lconn_status = LDAP_CONNST_CONNECTED; + break; + + default: + rc = -1; + return rc; + case -2: + /* connect not completed yet */ + ld->ld_errno = LDAP_X_CONNECTING; + return rc; + } + +#ifdef HAVE_TLS + if ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + !strcmp( srv->lud_scheme, "ldaps" )) { + + ++lc->lconn_refcnt; /* avoid premature free */ + + rc = ldap_int_tls_start( ld, lc, srv ); + + --lc->lconn_refcnt; + } +#endif + return rc; +} -- -- 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#6964) ./configure bug when specifying openssl as the TLS library to use
by the_uhu＠hotmail.com 08 Jun '11

08 Jun '11

--_845f4083-7211-40a8-bc3d-f1e94a6babb0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAglue -lrsaref $LIBS" Also checked the source repository on the website and it's there also. Can you please double check? Paul. > Date: Wed=2C 8 Jun 2011 22:13:55 +0000 > From: openldap-its(a)OpenLDAP.org > To: the_uhu(a)hotmail.com > Subject: Re: (ITS#6964) ./configure bug when specifying openssl as the TL= S library to use >=20 > I don't know where your configure script came from=2C but there's nothing= related > to OpenSSL at line 19408 of the current released configure script=2C and = our > script has had logic to detect -lrsaref since 1999. >=20 > Closing this ITS. Use the actual configure script supplied by the OpenLDA= P > Project. = --_845f4083-7211-40a8-bc3d-f1e94a6babb0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAgl= ue -lrsaref $LIBS" Also checked the source repository on the website= and it's there also. Can you please double check? Paul. <= br> &gt=3B Date: Wed=2C 8 Jun 2011 22:13:55 +0000 &gt=3B From: openld= ap-its(a)OpenLDAP.org &gt=3B To: the_uhu(a)hotmail.com &gt=3B Subject: Re= : (ITS#6964) ./configure bug when specifying openssl as the TLS library to = use &gt=3B &gt=3B I don't know where your configure script came from= =2C but there's nothing related &gt=3B to OpenSSL at line 19408 of the c= urrent released configure script=2C and our &gt=3B script has had logic = to detect -lrsaref since 1999. &gt=3B &gt=3B Closing this ITS. Use t= he actual configure script supplied by the OpenLDAP &gt=3B Project. = </body> </html>= --_845f4083-7211-40a8-bc3d-f1e94a6babb0_--

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by quanah＠zimbra.com 08 Jun '11

08 Jun '11

--On Friday, October 29, 2010 4:35 PM +0000 mark.cave-ayland(a)siriusit.co.uk wrote: > Hi all, > > An update on this bug report: with a modified slapd.conf and a small > patch to the back-perl module, I can use the ACL mask to ensure that the > perl search function doesn't get invoked if disallowed by the ACLs. > > The patch works by creating a "fake" empty entry whose DN is the base of > the search, and then passing this entry into access_allowed() using code > borrowed from one of the other backends to either deny or allow access. > > http://pastebin.siriusit.co.uk/perlacl/slapd2.conf > http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch These are not accessible. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 08 Jun '11

08 Jun '11

----- "Howard Chu" <hyc(a)symas.com> wrote: > Howard Chu wrote: > > Tyler Gates wrote: > >> After applying the patches for ITS #6848 and ITS #6898 I still get > crashes. > >> Here's the latest: > > ??? neither #6848 nor #6898 are relevant to pcache. I figured probably not but thought it may be important to know in terms as this is not just a straight 2.4.25 build... > > I think you should try the RE24 branch at this point, as a number of > other > pcache-related fixes have been merged there. Are you referring to OPENLDAP_REL_ENG_2_4 in the git tree? I'm not sure if I'll have the time (work) to tackle that but I'll see what I can do. > > > > Looks like a double-free. Can you reproduce this consistently? If > so, what are > > the steps? can you run slapd under valgrind and reproduce this? I can reproduce it consistently in terms that it crashes reliably after 2 to 4 days with 1 to 2 Linux hosts connected via pam-ldap account sessions. Other than that I've not been able to find a way to make it crash on demand. I do know it won't crash if it is run in the foreground with -d -1. I'm running it now under valgrind, any options you are looking for in particular? I'll report back the next time it crashes and/or I can try RE24. > >> > >> Program received signal SIGABRT, Aborted. > >> [Switching to Thread 0xae1edb70 (LWP 6121)] > >> 0xb76e2430 in __kernel_vsyscall () > >> (gdb) > >> (gdb) > >> (gdb) bt > >> #0 0xb76e2430 in __kernel_vsyscall () > >> #1 0xb71b4651 in *__GI_raise (sig=6) at > >> ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > >> #2 0xb71b7a82 in *__GI_abort () at abort.c:92 > >> #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** > glibc > >> detected *** %s: %s: 0x%s ***\n") at > >> ../sysdeps/unix/sysv/linux/libc_fatal.c:189 > >> #4 0xb71f5591 in malloc_printerr (action=<value optimized out>, > str=0x6 > >> <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266 > >> #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value > >> optimized out>) at malloc.c:4794 > >> #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at > malloc.c:3738 > >> #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2 > >> #8 0xb768acaf in ber_bvarray_free_x () from > /usr/lib/liblber-2.4.so.2 > >> #9 0xb768acf5 in ber_bvarray_free () from > /usr/lib/liblber-2.4.so.2 > >> #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at > >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148 > >> #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at > >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198 > >> #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac, > >> newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at > cache.c:1238 > >> #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at > modify.c:662 > >> #14 0xb6d52e81 in remove_query_data (op=<value optimized out>, > >> query_uuid=<value optimized out>) > >> at > /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829 > >> #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, > arg=0xb955e018) at > >> /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520 > >> #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2 > >> #17 0xb72e996e in start_thread (arg=0xae1edb70) at > pthread_create.c:300 > >> #18 0xb7257a4e in clone () at > ../sysdeps/unix/sysv/linux/i386/clone.S:130 > >> (gdb) continue > >> Continuing. > >> [Thread 0xaddecb70 (LWP 6122) exited] > >> [Thread 0xae1edb70 (LWP 6121) exited] > >> [Thread 0xae7f0b70 (LWP 6120) exited] > >> [Thread 0xaedf3b70 (LWP 6119) exited] > >> [Thread 0xaf2f5b70 (LWP 6118) exited] > >> [Thread 0xaf7f7b70 (LWP 6117) exited] > >> [Thread 0xafbf8b70 (LWP 6116) exited] > >> [Thread 0xafff9b70 (LWP 6115) exited] > >> [Thread 0xb04fbb70 (LWP 6114) exited] > >> [Thread 0xb08fcb70 (LWP 6113) exited] > >> [Thread 0xb582ab70 (LWP 5868) exited] > >> [Thread 0xb5320b70 (LWP 5869) exited] > >> [Thread 0xb4e1eb70 (LWP 5870) exited] > >> [Thread 0xb4a1db70 (LWP 5871) exited] > >> [Thread 0xb461cb70 (LWP 5872) exited] > >> [Thread 0xb421bb70 (LWP 5873) exited] > >> [Thread 0xb5c2bb70 (LWP 5867) exited] > >> > >> Program terminated with signal SIGABRT, Aborted. > >> The program no longer exists. > >> (gdb) > >> > >> > > > > > > > -- > -- 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#6964) ./configure bug when specifying openssl as the TLS library to use
by Howard Chu 08 Jun '11

08 Jun '11

I don't know where your configure script came from, but there's nothing related to OpenSSL at line 19408 of the current released configure script, and our script has had logic to detect -lrsaref since 1999. Closing this ITS. Use the actual configure script supplied by the OpenLDAP Project.

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by hyc＠symas.com 08 Jun '11

08 Jun '11

Howard Chu wrote: > Tyler Gates wrote: >> After applying the patches for ITS #6848 and ITS #6898 I still get crashes. >> Here's the latest: ??? neither #6848 nor #6898 are relevant to pcache. I think you should try the RE24 branch at this point, as a number of other pcache-related fixes have been merged there. > > Looks like a double-free. Can you reproduce this consistently? If so, what are > the steps? can you run slapd under valgrind and reproduce this? >> >> Program received signal SIGABRT, Aborted. >> [Switching to Thread 0xae1edb70 (LWP 6121)] >> 0xb76e2430 in __kernel_vsyscall () >> (gdb) >> (gdb) >> (gdb) bt >> #0 0xb76e2430 in __kernel_vsyscall () >> #1 0xb71b4651 in *__GI_raise (sig=6) at >> ../nptl/sysdeps/unix/sysv/linux/raise.c:64 >> #2 0xb71b7a82 in *__GI_abort () at abort.c:92 >> #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** glibc >> detected *** %s: %s: 0x%s ***\n") at >> ../sysdeps/unix/sysv/linux/libc_fatal.c:189 >> #4 0xb71f5591 in malloc_printerr (action=<value optimized out>, str=0x6 >> <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266 >> #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value >> optimized out>) at malloc.c:4794 >> #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at malloc.c:3738 >> #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2 >> #8 0xb768acaf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2 >> #9 0xb768acf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2 >> #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148 >> #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198 >> #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac, >> newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at cache.c:1238 >> #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at modify.c:662 >> #14 0xb6d52e81 in remove_query_data (op=<value optimized out>, >> query_uuid=<value optimized out>) >> at /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829 >> #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, arg=0xb955e018) at >> /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520 >> #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2 >> #17 0xb72e996e in start_thread (arg=0xae1edb70) at pthread_create.c:300 >> #18 0xb7257a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 >> (gdb) continue >> Continuing. >> [Thread 0xaddecb70 (LWP 6122) exited] >> [Thread 0xae1edb70 (LWP 6121) exited] >> [Thread 0xae7f0b70 (LWP 6120) exited] >> [Thread 0xaedf3b70 (LWP 6119) exited] >> [Thread 0xaf2f5b70 (LWP 6118) exited] >> [Thread 0xaf7f7b70 (LWP 6117) exited] >> [Thread 0xafbf8b70 (LWP 6116) exited] >> [Thread 0xafff9b70 (LWP 6115) exited] >> [Thread 0xb04fbb70 (LWP 6114) exited] >> [Thread 0xb08fcb70 (LWP 6113) exited] >> [Thread 0xb582ab70 (LWP 5868) exited] >> [Thread 0xb5320b70 (LWP 5869) exited] >> [Thread 0xb4e1eb70 (LWP 5870) exited] >> [Thread 0xb4a1db70 (LWP 5871) exited] >> [Thread 0xb461cb70 (LWP 5872) exited] >> [Thread 0xb421bb70 (LWP 5873) exited] >> [Thread 0xb5c2bb70 (LWP 5867) exited] >> >> Program terminated with signal SIGABRT, Aborted. >> The program no longer exists. >> (gdb) >> >> > > -- -- 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#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by masarati＠aero.polimi.it 08 Jun '11

08 Jun '11

> masarati(a)aero.polimi.it wrote: >>> With your patch the response control is now decoded correctly and it >>> behaves >>> as expected for all operations except Modify DN Operation: >>> It returns empty value lists for all attributes no matter how >>> deleteoldrdn >>> is >>> set. The DN returned is correct. >> >> I suspect ors_attrsonly is set by mistake. Please try this: >> >> + myop.ors_attrsonly = 0; > > With your last patch everything works as expected now. Thanks a lot. Great. I've committed it. Thanks, p.

1 0

Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by michael＠stroeder.com 08 Jun '11

08 Jun '11

masarati(a)aero.polimi.it wrote: >> With your patch the response control is now decoded correctly and it >> behaves >> as expected for all operations except Modify DN Operation: >> It returns empty value lists for all attributes no matter how deleteoldrdn >> is >> set. The DN returned is correct. > > I suspect ors_attrsonly is set by mistake. Please try this: > > + myop.ors_attrsonly = 0; With your last patch everything works as expected now. Thanks a lot. Ciao, Michael.

1 0

Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by masarati＠aero.polimi.it 08 Jun '11

08 Jun '11

> Pierangelo Masarati wrote: >> On 06/07/2011 12:58 PM, michael(a)stroeder.com wrote: >>> Any chance this will be fixed? >>> >>> It would be very handy for sync processes to get back the entryUUID >>> generated >>> by OpenLDAP of a new entry in an AddResponse without having to read the >>> new >>> entry once more. >> >> If I get things right, what seems to be missing is a >> LDAP_RES_SEARCH_ENTRY tag >> right before encoding the search entry, something like > > [..patch snipped..] > > Thanks! > > With your patch the response control is now decoded correctly and it > behaves > as expected for all operations except Modify DN Operation: > It returns empty value lists for all attributes no matter how deleteoldrdn > is > set. The DN returned is correct. > > Here's the trace log from the Python script: > > ----------------------------- snip ----------------------------- > *** ldap://localhost:2071/ - SimpleLDAPObject.rename > (('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2', > None, > 0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{}) > => result: 5 > *** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0, > 0),{}) > => result: (109, [], 5, [('1.3.6.1.1.13.2', 0, > 'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')]) > resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local > resp_ctrls[0].entry: > {'cn': [], > 'createTimestamp': [], > 'creatorsName': [], > 'entryCSN': [], > 'entryDN': [], > 'entryUUID': [], > 'gidNumber': [], > 'hasSubordinates': [], > 'homeDirectory': [], > 'modifiersName': [], > 'modifyTimestamp': [], > 'objectClass': [], > 'structuralObjectClass': [], > 'subschemaSubentry': [], > 'uid': [], > 'uidNumber': []} > ----------------------------- snip ----------------------------- I suspect ors_attrsonly is set by mistake. Please try this: --- a/servers/slapd/result.c +++ b/servers/slapd/result.c @@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs ) #endif if ( op->o_res_ber ) { /* read back control */ - rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name ); + rc = ber_printf( ber, "t{O{" /*}}*/, + LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); } else { rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid, LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); @@ -1744,6 +1745,7 @@ int slap_read_controls( myop.o_res_ber = ber; myop.o_callback = NULL; myop.ors_slimit = 1; + myop.ors_attrsonly = 0; rc = slap_send_search_entry( &myop, rs ); if( rc ) return rc;

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs