From nkinder at redhat.com Thu Jun 5 13:10:55 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 05 Jun 2008 09:10:55 -0400 Subject: [Fedora-directory-devel] Please Review: (450107) memberOf: Add config entry to dse.ldif template Message-ID: <4847E5DF.6050600@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=450107 Resolves: bug 450107 Bug Description: We should put a config entry for the memberOf plug-in in the default dse.ldif. This plug-in should be off by default. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Added config entry to dse.ldif template. Platforms tested: F9 i386 Flag Day: No. Doc impact: None. https://bugzilla.redhat.com/attachment.cgi?id=308434&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Mon Jun 9 18:55:43 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 09 Jun 2008 11:55:43 -0700 Subject: [Fedora-directory-devel] Please Review: (443241) Fixup task does not fix memberOf attribute of indirect groups Message-ID: <484D7CAF.6060205@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=443241 Resolves: bug 443241 Bug Description: The memberOf fixup task doesn't always add an indirect group to the memberOf attribute of an entry. This is dependent on what values are currently present in the user entry. The code basically assumes that if a group is present, that all indirect parent groups should already be present as well, which is not always the case. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix is to not assume anything about the state of an entry when we fix it up. We should just remove any present values of the memberOf attribute and generate the entire correct list. Platforms tested: F9 i386 Flag Day: No. Doc impact: None. https://bugzilla.redhat.com/attachment.cgi?id=308743&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Jun 10 20:02:18 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 10 Jun 2008 13:02:18 -0700 Subject: [Fedora-directory-devel] Please Review: (450746) Add CLI for memberOf fix-up task Message-ID: <484EDDCA.7030301@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=450746 Resolves: bug 450746 Bug Description: A CLI needs to be provided for creating a memberOf fix-up task. This should work the same as our other existing task creation perl scripts. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Created a new script template that just adds the proper memberOf fixup task entry. Platforms tested: F9 i386 Flag Day: No. Doc impact: Yes, this CLI will need to be doc'd. https://bugzilla.redhat.com/attachment.cgi?id=308853 https://bugzilla.redhat.com/attachment.cgi?id=308855&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Jun 11 19:34:39 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 11 Jun 2008 13:34:39 -0600 Subject: [Fedora-directory-devel] Please review: Bug 449178: Hard-coded java path limitting the installation flexibility Message-ID: <485028CF.9090208@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=449178 Resolves: bug 449178 Bug Description: Hard-coded java path limitting the installation flexibility Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Allow the user to specify JAVA_HOME to override the default javahome location. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=308983&action=diff From nkinder at redhat.com Thu Jun 12 04:21:35 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 11 Jun 2008 21:21:35 -0700 Subject: [Fedora-directory-devel] Please Review: (450989) memberOf: Make group and memberOf attributes configurable Message-ID: <4850A44F.2050308@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=450989 Resolves: bug 450989 Bug Description: The memberOf plug-in is currently hardcoded to use the "member" and "memberOf" attributes for group membership. These attributes should be configurable. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix allows these attributes to be configured in the plug-in configuration entry. The configuration can be dynamically changed over LDAP with the server running. We ensure that the configuration doesn't change while a memberOf operation is in progress by obtaining the memberOf lock while the changes are applied. I also made the filter that is used to check if a group membership change is made a part of the configuration struct since it is based off of one of the configurable attributes. In addition to the above changes, I removed an unnecessary function that was wrapping slapi_str2filter(). The previous code was doing a malloc of the filter string, needlessly duplicating the string, then creating the Slapi_Filter (which does a malloc as well). The two copies of the filter string were then just free'd. This was inefficient, so I removed the wrapper function so that we simply malloc the filter string and pass it to slapi_str2filter() to allocate the Slapi_Filter. This saves us one malloc/free. Platforms tested: F9 i386 Flag Day: No. Doc impact: Yes, the config attributes will need to be doc'd. https://bugzilla.redhat.com/attachment.cgi?id=309023&action=diff https://bugzilla.redhat.com/attachment.cgi?id=309024 https://bugzilla.redhat.com/attachment.cgi?id=309025 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From sztupi at nava.hu Thu Jun 19 14:52:33 2008 From: sztupi at nava.hu (=?ISO-8859-1?Q?=22Sztup=E1k_Sz=2E_Zsolt=22?=) Date: Thu, 19 Jun 2008 16:52:33 +0200 Subject: [Fedora-directory-devel] Using Directory Client without an admin server running Message-ID: <485A72B1.3040209@nava.hu> Hi! I was just curious: Is it officially possible to use the directory client for LDAP-related jobs without having an admin server running? I mean most of the things you'll use the client for is LDAP related (adding-removing users, changing attributes, changing ACLs, etc.), and there is no need for an admin server to be running. Unofficially I managed to hack a small groovy script that will run the DS client (inside fedora-ds-1.1.jar) and connect to a server. Browsing the directory and changing attributes works, but adding a new entry, or changing ACL-s will crash the program (but I'm trying to figure out why). You still need an "o=netscaperoot" base in your LDAP directory, but at least the admin server need not be running (we are running a service on a Gentoo Linux based machine with Lighttpd, and don't want to use/install Apache). SztupY console.groovy: // create a fedora-ds-1.1.jar in your home directory containing all classes (merge all jar files IDM uses into one named fedora-ds-1.1.jar) for this script to work import com.netscape.admin.dirserv.DSAdmin; import com.netscape.management.client.console.*; import com.netscape.management.client.util.Debug; import java.awt.*; import netscape.ldap.*; com.netscape.management.client.util.Debug.setTraceLevel(9); DSAdmin d = new DSAdmin(); ConsoleInfo i = new ConsoleInfo("HOST_NAME",389,"USER_NAME","PASSWORD","o=NetscapeRoot"); LDAPConnection c = new LDAPConnection(); c.connect("HOST_NAME",389,"USER_NAME","PASSWORD"); i.setLDAPConnection(c); i.setCurrentDN("cn=SERVER_NAME,cn=fedora directory server,cn=server group,cn=HOST_NAME,o=netscaperoot"); i.setAdminOS("Windows"); // in Windows d.initialize(i); Component cc = d.getCustomPanel(); d.select(null); d.run(null); From rmeggins at redhat.com Thu Jun 19 23:19:58 2008 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 19 Jun 2008 19:19:58 -0400 Subject: [Fedora-directory-devel] Using Directory Client without an admin server running In-Reply-To: <485A72B1.3040209@nava.hu> References: <485A72B1.3040209@nava.hu> Message-ID: <485AE99E.2080702@redhat.com> Sztup?k Sz. Zsolt wrote: > Hi! > > I was just curious: Is it officially possible to use the directory > client for LDAP-related jobs without having an admin server running? I > mean most of the things you'll use the client for is LDAP related > (adding-removing users, changing attributes, changing ACLs, etc.), and > there is no need for an admin server to be running. > > Unofficially I managed to hack a small groovy script that will run the > DS client (inside fedora-ds-1.1.jar) and connect to a server. Browsing > the directory and changing attributes works, but adding a new entry, > or changing ACL-s will crash the program (but I'm trying to figure out > why). You still need an "o=netscaperoot" base in your LDAP directory, > but at least the admin server need not be running (we are running a > service on a Gentoo Linux based machine with Lighttpd, and don't want > to use/install Apache). Yes, it should work. I would first suggest taking a look at the main Console code - there used to be a command line switch that would allow you to go directly to the server you wanted to edit, and pass in the admin auth credentials too. It's that auth part that may require the admin server. Please paste the output of running your script to fpaste.org and paste the link here - perhaps we can help debug it. > > SztupY > > console.groovy: > // create a fedora-ds-1.1.jar in your home directory containing all > classes (merge all jar files IDM uses into one named > fedora-ds-1.1.jar) for this script to work > import com.netscape.admin.dirserv.DSAdmin; > import com.netscape.management.client.console.*; > import com.netscape.management.client.util.Debug; > import java.awt.*; > import netscape.ldap.*; > com.netscape.management.client.util.Debug.setTraceLevel(9); > DSAdmin d = new DSAdmin(); > ConsoleInfo i = new > ConsoleInfo("HOST_NAME",389,"USER_NAME","PASSWORD","o=NetscapeRoot"); > LDAPConnection c = new LDAPConnection(); > c.connect("HOST_NAME",389,"USER_NAME","PASSWORD"); > i.setLDAPConnection(c); > i.setCurrentDN("cn=SERVER_NAME,cn=fedora directory server,cn=server > group,cn=HOST_NAME,o=netscaperoot"); > i.setAdminOS("Windows"); // in Windows > d.initialize(i); > Component cc = d.getCustomPanel(); > d.select(null); > d.run(null); > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Fri Jun 20 23:29:30 2008 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 20 Jun 2008 16:29:30 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 437525] GER: allow GER for non-existing entries In-Reply-To: <200806202324.m5KNOEUA023365@bz-web1.app.phx.redhat.com> References: <200806202324.m5KNOEUA023365@bz-web1.app.phx.redhat.com> Message-ID: <485C3D5A.6080202@redhat.com> Summary: GER: allow GER for non-existing entries https://bugzilla.redhat.com/show_bug.cgi?id=437525 FDS is trying to support these requirements. http://directory.fedoraproject.org/wiki?title=Get_Effective_Rights_for_non-present_attributes#Overview > Get Effective Rights is enhanced to support these requirements: > > 1. a requester should be able to see the effective rights of each > entry returned from the search request if the subject user is > identical to the requester. This functionality can be used, e.g., for > an address card to determine which fields to be writable and to be > grayed out depending upon the user who opens the card. > > 2. the attribute list to be retrieved accepts '*' for the all the > available attributes belonging to the returned entry as well as '+' > for the operational attributes to allow the requester get the > effective rights of all the non-existing attributes. > > 3. the attribute list to be retrieved accepts > "@", where is an attribute type (e.g., > cn) or '*' for all attributes and is a type of > objectclass (e.g., inetorgperson). > Your reviews would be greatly appreciated. --noriko ------- Additional Comments From nhosoi at redhat.com 2008-06-20 19:24 EST ------- Created an attachment (id=309953) --> (https://bugzilla.redhat.com/attachment.cgi?id=309953&action=view) cvs diffs Files: ldap/servers/slapd/charray.c ldap/servers/slapd/opshared.c ldap/servers/slapd/pblock.c ldap/servers/slapd/result.c ldap/servers/slapd/schema.c ldap/servers/slapd/search.c ldap/servers/slapd/slapi-plugin.h ldap/servers/slapd/slapi-private.h ldap/servers/plugins/acl/acleffectiverights.c ldap/servers/plugins/chainingdb/cb_config.c ldap/servers/plugins/chainingdb/cb_controls.c ldap/servers/plugins/chainingdb/cb_instance.c Change descriptions: [slapd/charray.c] new: charray_merge_nodup -- merge 2 string arrays skipping the duplicates modified: charray_remove -- introduced "freeit" flag. If true, the removed string is freed. (The API is used only in chainingdb. The change is applied to the plugin.) [slapd/opshared.c] modified: check OP_FLAG_GET_EFFECTIVE_RIGHTS in the iterate to support "@". It's needed to do at the location since we have to call acl plugin even when no entries are returned from the search. If no entries are returned and "@" is found in the attribute list, acl effective rights code generates the corresponding template entry. [slapd/pblock.c] place to store gerattrs is added (SLAPI_SEARCH_GERATTRS), where gerattrs is an array of strings which store "...@". [slapd/result.c] moved OP_FLAG_GET_EFFECTIVE_RIGHTS checking to iterate (opshared.c) [slapd/schema.c] new: slapi_schema_list_objectclass_attributes -- return the required and/or allowed attributes belonging to the given objectclass. This is used to support "*" and "+" in the get effective rights. new: slapi_schema_get_superior_name -- return the superior objectclass name of the given objectclass. [slapd/search.c] if "@" is found in the attribute list, cut the part out and added to the attrs array (pblock SLAPI_SEARCH_ATTRS) and store the original string to the gerattrs (pblock SLAPI_SEARCH_GERATTRS). [plugin/acl/acleffectiverights.c] modified: _ger_g_permission_granted -- if the requester and the subject user are identical, give "g" permission modified: _ger_parse_control -- replaced strcpy with memmove since strcpy does not guarantee the result of the overlap copy. modified: _ger_get_attrs_rights -- support "*" (all attributes belonging to the object) and "+" (operational attributes). If repeated attributes are found in the given attribute list, they are reduced to one. new: _ger_generate_template_entry -- generate a template entry if "@" is passed. [pluginc/cb/*] adjusted to the updated charray_remove. Please see also this wiki page for the overview and test cases. http://directory.fedoraproject.org/wiki/Get_Effective_Rights_for_non-present_attributes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Jun 23 17:21:52 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 23 Jun 2008 11:21:52 -0600 Subject: [Fedora-directory-devel] Please review: Bug 233642: MMR breaks with time skew errors Message-ID: <485FDBB0.4090602@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=233642 Resolves: bug 233642 Bug Description: MMR breaks with time skew errors Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: CSN remote offset generation seems broken. We seem to accumulate a remote offset that keeps growing until we hit the limit of 1 day, then replication stops. The idea behind the remote offset is that servers may be seconds or minutes off. When replication starts, one of the itmes in the payload of the start extop is the latest CSN from the supplier. The CSN timestamp field is (sampled_time + local offset + remote offset). Sampled time comes from the time thread in the server that updates the time once per second. This allows the consumer, if also a master, to adjust its CSN generation so as not to generate duplicates or CSNs less than those from the supplier. However, the logic in csngen_adjust_time appears to be wrong: remote_offset = remote_time - gen->state.sampled_time; That is, remote_offset = (remote sampled_time + remote local offset + remote remote offset) - gen->state.sampled_time It should be remote_offset = remote_time - (sampled_time + local offset + remote offset) Since the sampled time is not the actual current time, it may be off by 1 second. So the new remote_offset will be at least 1 second more than it should be. Since this is the same remote_offset used to generate the CSN to send back to the other master, this offset would keep increasing and increasing over time. The script attached to the bug helps measure this effect. The new code also attempts to refresh the sampled time while adjusting to make sure we have as current a sampled_time as possible. In the old code, the remote_offset is "sent" back and forth between the masters, carried along in the CSN timestamp generation. In the new code, this can happen too, but to a far less extent, and should max out at (real offset + N seconds) where N is the number of masters. In the old code, you could only call csngen_adjust_time if you first made sure the remote timestamp >= local timestamp. I have removed this restriction and moved that logic into csngen_adjust_time. I also cleaned up the code in the consumer extop - I combined the checking of the CSN from the extop with the max CSN from the supplier RUV - now we only adjust the time once based on the max of all of these CSNs sent by the supplier. Finally, I cleaned up the error handling in a few places that assumed all errors were time skew errors. Platforms tested: RHEL5, F8, F9 Flag Day: no Doc impact: no QA impact: Should test MMR and use the script to measure the offset effect. https://bugzilla.redhat.com/attachment.cgi?id=310040&action=diff From rmeggins at redhat.com Mon Jun 23 17:26:32 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 23 Jun 2008 11:26:32 -0600 Subject: [Fedora-directory-devel] Please review: Bug 442170: "DB_BUFFER_SMALL: User memory too small for return value" error when importing LDIF with replication active Message-ID: <485FDCC8.1010201@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=442170 Resolves: bug 442170 Bug Description: "DB_BUFFER_SMALL: User memory too small for return value" error when importing LDIF with replication active Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: BDB 4.3 does not use ENOMEM if the given buffer is too small - it uses DB_BUFFER_SMALL. This fix allows use to use DB_BUFFER_SMALL in 4.2 and earlier too. I also cleaned up some of the cl5 api return codes to return an appropriate error code to the higher levels rather than pass the ENOMEM up. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=310041&action=diff From rmeggins at redhat.com Mon Jun 23 17:46:23 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 23 Jun 2008 11:46:23 -0600 Subject: [Fedora-directory-devel] Please review: Bug 452018: The default url for is missing dc=com Message-ID: <485FE16F.9080506@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=452018 Resolves: bug 452018 Bug Description: The default url for is missing dc=com Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Several values in the config files needed to be quoted. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=310047&action=diff From abartlet at samba.org Tue Jun 24 01:50:21 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 24 Jun 2008 11:50:21 +1000 Subject: [Fedora-directory-devel] Please review: [Bug 437525] GER: allow GER for non-existing entries In-Reply-To: <485C3D5A.6080202@redhat.com> References: <200806202324.m5KNOEUA023365@bz-web1.app.phx.redhat.com> <485C3D5A.6080202@redhat.com> Message-ID: <1214272221.13450.59.camel@naomi> On Fri, 2008-06-20 at 16:29 -0700, Noriko Hosoi wrote: > Summary: GER: allow GER for non-existing entries > > https://bugzilla.redhat.com/show_bug.cgi?id=437525 > > FDS is trying to support these requirements. > > http://directory.fedoraproject.org/wiki?title=Get_Effective_Rights_for_non-present_attributes#Overview While I would still like this to just appear as an attribute (requested by inclusion in the attributes list in a search) this, subject to testing at a later time, seems to meet Samba4's requirements. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Tue Jun 24 21:49:35 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 24 Jun 2008 15:49:35 -0600 Subject: [Fedora-directory-devel] Please review: Bug 233642: MMR breaks with time skew errors In-Reply-To: <485FDBB0.4090602@redhat.com> References: <485FDBB0.4090602@redhat.com> Message-ID: <48616BEF.3060701@redhat.com> Rich Megginson wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=233642 > Resolves: bug 233642 > Bug Description: MMR breaks with time skew errors > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: CSN remote offset generation seems broken. We seem > to accumulate a remote offset that keeps growing until we hit the > limit of 1 day, then replication stops. The idea behind the remote > offset is that servers may be seconds or minutes off. When > replication starts, one of the itmes in the payload of the start extop > is the latest CSN from the supplier. The CSN timestamp field is > (sampled_time + local offset + remote offset). Sampled time comes > from the time thread in the server that updates the time once per > second. This allows the consumer, if also a master, to adjust its CSN > generation so as not to generate duplicates or CSNs less than those > from the supplier. However, the logic in csngen_adjust_time appears > to be wrong: > remote_offset = remote_time - gen->state.sampled_time; > That is, remote_offset = (remote sampled_time + remote local offset + > remote remote offset) - gen->state.sampled_time > It should be > remote_offset = remote_time - (sampled_time + local offset + > remote offset) > Since the sampled time is not the actual current time, it may be off > by 1 second. So the new remote_offset will be at least 1 second more > than it should be. Since this is the same remote_offset used to > generate the CSN to send back to the other master, this offset would > keep increasing and increasing over time. The script attached to the > bug helps measure this effect. The new code also attempts to refresh > the sampled time while adjusting to make sure we have as current a > sampled_time as possible. In the old code, the remote_offset is > "sent" back and forth between the masters, carried along in the CSN > timestamp generation. In the new code, this can happen too, but to a > far less extent, and should max out at (real offset + N seconds) where > N is the number of masters. > In the old code, you could only call csngen_adjust_time if you first > made sure the remote timestamp >= local timestamp. I have removed > this restriction and moved that logic into csngen_adjust_time. I also > cleaned up the code in the consumer extop - I combined the checking of > the CSN from the extop with the max CSN from the supplier RUV - now we > only adjust the time once based on the max of all of these CSNs sent > by the supplier. > Finally, I cleaned up the error handling in a few places that assumed > all errors were time skew errors. > Platforms tested: RHEL5, F8, F9 > Flag Day: no > Doc impact: no > QA impact: Should test MMR and use the script to measure the offset > effect. > https://bugzilla.redhat.com/attachment.cgi?id=310040&action=diff Quick follow up - I found a bug in my previous patch - _csngen_adjust_local_time must not be called when the sampled time == the current time. So I fixed that where I was calling _csngen_adjust_local_time, and I also changed _csngen_adjust_local_time so that time_diff == 0 is a no-op. You can view the diffs of the diff here - https://bugzilla.redhat.com/attachment.cgi?oldid=310040&action=interdiff&newid=310193&headers=1 > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Wed Jun 25 18:15:21 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 25 Jun 2008 11:15:21 -0700 Subject: [Fedora-directory-devel] Please Review: (452537) Infinite recursion caused by missing entry in memberOf plug-in Message-ID: <48628B39.9060609@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=452537 Resolves: bug 452537 Bug Description: When processing certain memberOf related operations, a missing member entry can cause the memberOf plug-in to infinitely recurse, causing ns-slapd to crash whenit runs out of stack space. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: See https://bugzilla.redhat.com/process_bug.cgi#c1 Platforms tested: F9 i386 Flag Day: No. Doc impact: No. https://bugzilla.redhat.com/attachment.cgi?id=310173&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: