- openldap-bugs - openldap.org

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 12 Jun '11

12 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 10 Jun '11

10 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 10 Jun '11

10 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 10 Jun '11

10 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 10 Jun '11

10 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 10 Jun '11

10 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 10 Jun '11

10 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 10 Jun '11

10 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs