openldap-bugs June 2011

openldap-bugs@openldap.org

35 participants
131 discussions

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

← Newer
1
2
3
4
5
6
7
8
9
...
14
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2011