From nhosoi at redhat.com Tue Nov 4 16:14:38 2008 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 04 Nov 2008 08:14:38 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 462922] Import of data does not record timestamps... In-Reply-To: <200811040728.mA47SUGi002463@bz-web1.app.phx.redhat.com> References: <200811040728.mA47SUGi002463@bz-web1.app.phx.redhat.com> Message-ID: <491074EE.7010605@redhat.com> [Bug 462922] Import of data does not record timestamps... https://bugzilla.redhat.com/show_bug.cgi?id=462922 [Problem description] During the setup, I import a ldif file, which contains just the suffix object (with the InstallLdifFile option during silent setup). The createTimestamp and modifyTimestamp operational attributes were not generated during this import. This eventually leads into a WARNING message, when I create vlv indexes for the timestamp attributes. See the following thread from the mailing list. https://www.redhat.com/archives/fedora-directory-users/2008-September/msg00084.html Comment by Rich in the mailing list: createTimestamp should be present, unless you have nsslapd-lastmod turned off. [Fix proposal] --> (https://bugzilla.redhat.com/attachment.cgi?id=322441) cvs diff ldap/servers/slapd/back-ldbm/import-threads.c File: ldapserver/ldap/servers/slapd/back-ldbm/import-threads.c Description: add a static function import_add_created_attrs to add CreatorsName, ModifiersName, CreateTimestamp, ModifyTimestamp to each imported entry. I also added a check if nsslapd-lastmod is on or off. It adds the created info only if the lastmod is on. Sample entry: dn: dc=example,dc=com objectClass: top [...] nsUniqueId: ce7e5ea2-aa4011dd-b970c0aa-ead44d23 creatorsName: modifiersName: createTimestamp: 20081104071841Z modifyTimestamp: 20081104071841Z Please note: creatorsName and modifiersName are empty. I followed the "add" case, which leaves the names empty when the creator's name is not available. For the imported entries, we can choose not to put the name lines at all. I'd like to have your comments on it, which would be more reasonable. Thanks, --noriko -------------- 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 nhosoi at redhat.com Wed Nov 5 02:51:16 2008 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 04 Nov 2008 18:51:16 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 469792] vlvindex should not give an error message when the vlvindex is empty In-Reply-To: <200811040221.mA42Lfah009679@bz-web2.app.phx.redhat.com> References: <200811040221.mA42Lfah009679@bz-web2.app.phx.redhat.com> Message-ID: <49110A24.1000704@redhat.com> Summary: vlvindex should not give an error message when the vlvindex is empty https://bugzilla.redhat.com/show_bug.cgi?id=469792 Description of problem: vlvindex should not give an error message - either its a real error (not sure why) or the error message is spurious and should not be printed by default [error message sample] $ vlvindex -n userRoot -T "by roomNumber" [03/Nov/2008:18:16:05 -0800] - userRoot: Indexing VLV: by roomNumber [03/Nov/2008:18:16:05 -0800] - warning: entrydn not indexed on 'ou=payroll,dc=example,dc=com' [03/Nov/2008:18:16:05 -0800] - userRoot: WARNING: Failed to fetch subtree lists: (-30989) DB_NOTFOUND: No matching key/data pair found [03/Nov/2008:18:16:05 -0800] - userRoot: Possibly the entrydn or ancestorid index is corrupted or does not exist. [03/Nov/2008:18:16:05 -0800] - userRoot: Attempting brute-force method instead. [03/Nov/2008:18:16:05 -0800] - userRoot: Finished indexing. [03/Nov/2008:18:16:05 -0800] - All database threads now stopped When ou=payroll, dc=example, dc=com or its descendants do not exist, this "Possibly broken or does not exist" message is issued. This is not a false message since it mentions the case the entry does not exist. Internally, we could distinguish the broken case from not existing case. Thus, we'd better suppress unnecessary warnings. This proposed code does so. [Proposed fix] Created an attachment (id=322519) --> (https://bugzilla.redhat.com/attachment.cgi?id=322519) cvs diff ldap/servers/slapd/back-ldbm/ldif2ldbm.c File: ldap/servers/slapd/back-ldbm/ldif2ldbm.c Fix description: In ldbm_fetch_subtrees (ldif2ldbm.c), if the parent entry to be vlvindexed ('ou=payroll,dc=example,dc=com' in this example) does not exist, then vlvindex with the proposed code issues this warning but no further messages. warning: entrydn not indexed on 'ou=payroll,dc=example,dc=com'; entry ou=payroll,dc=example,dc=com may not be added to the database yet. If the parent entry exists (entry id 10 in this example), but no descendant entries to be vlvindexed do not, then vlvindex with the proposed code issues this warning but no further messages. warning: ancestorid not indexed on 10; possibly, the entry id 10 has no descendants yet. The bug 469792 has the test cases and vlvindex output samples. Thanks, --noriko -------------- 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 Wed Nov 5 17:06:07 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 05 Nov 2008 10:06:07 -0700 Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL - part 2 Message-ID: <4911D27F.6000400@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=469261 Resolves: bug 469261 Bug Description: Support server-to-server SASL - part 2 Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: This part focuses on chaining backend - allowing the mux server to use SASL to connect to the farm server, and allowing SASL authentication to chain. I had to add two new config parameters for chaining: nsUseStartTLS - on or off - tell connection to use startTLS - default is off nsBindMechanism - if absent, will just use simple auth. If present, this must be one of the supported mechanisms (EXTERNAL, GSSAPI, DIGEST-MD5) - default is absent (simple bind) The chaining code uses a timeout, so I had to add a timeout to slapi_ldap_bind, and correct the replication code to pass in a NULL for the timeout parameter. Fixed a bug in the starttls code in slapi_ldap_init_ext. The sasl code uses an internal search to find the entry corresponding to the sasl user id. This search could not be chained due to the way it was coded. So I added a new chainable component called cn=sasl and changed the sasl internal search code to use this component ID. This allows the sasl code to work with a chained backend. In order to use chaining with sasl, this component must be set in the chaining configuration nsActiveChainingComponents. I also discovered that password policy must be configured too, in order for the sasl code to determine if the account is locked out. I fixed a bug in the sasl mapping debug trace code. Still to come - sasl mappings to work with all of this new code - kerberos code improvements - changes to pta and dna Platforms tested: Fedora 8, Fedora 9 Flag Day: yes Doc impact: yes https://bugzilla.redhat.com/attachment.cgi?id=322613&action=diff From rmeggins at redhat.com Thu Nov 6 21:45:22 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 06 Nov 2008 14:45:22 -0700 Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL - kerberos improvements Message-ID: <49136572.2030802@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=469261 Resolves: bug 469261 Bug Description: Support server-to-server SASL - kerberos improvements Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I made several improvements to the kerberos code at Simo's suggestion First look for the principal in the ccache. If not found, use the username if it does not look like a DN. If still not found, construct a principal using the krb5_sname_to_principal() function to construct "ldap/fqdn at REALM". Next, see if the credentials for this principal are still valid. In order to grab the credentials from the ccache, I needed to construct the server principal, which in this case is the TGS service principal (e.g. krbtgt/REALM at REALM). If the credentials are present and not expired, then the code assumes they are ok and does not acquire new credentials. If the credentials are expired or not found, the code will then use the keytab to authenticate. Platforms tested: Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=322788&action=diff From rmeggins at redhat.com Fri Nov 7 23:34:41 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 07 Nov 2008 16:34:41 -0700 Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL - better kerberos improvements Message-ID: <4914D091.8080202@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=469261 Resolves: bug 469261 Bug Description: Support server-to-server SASL - kerberos improvements Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I made several improvements to the kerberos code at Simo's suggestion First look for the principal in the ccache. If not found, use the username if it does not look like a DN. If still not found, construct a principal using the krb5_sname_to_principal() function to construct "ldap/fqdn at REALM". Next, see if the credentials for this principal are still valid. In order to grab the credentials from the ccache, I needed to construct the server principal, which in this case is the TGS service principal (e.g. krbtgt/REALM at REALM). If the credentials are present and not expired, then the code assumes they are ok and does not acquire new credentials. If the credentials are expired or not found, the code will then use the keytab to authenticate. Based on more feedback from Simo, I made some additional changes: * Go ahead and reacquire the creds if they have expired or will expire in 30 seconds - this is not configurable but could be made to be - 30 seconds should be long enough so that the credentials will not expire by the time they are actually used deep in the ldap/sasl/gssapi/krb code, and short enough so that this won't cause unnecessary credential churn * Retry the bind in the case of Ticket expired. There is no way that I can see to get the actual error code - fortunately the extended ldap error message has this information Platforms tested: Fedora 8, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=322914&action=diff From rmeggins at redhat.com Fri Nov 7 23:47:13 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 07 Nov 2008 16:47:13 -0700 Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL - part 3 - dna plugin Message-ID: <4914D381.3040003@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=469261 Resolves: bug 469261 Bug Description: Support server-to-server SASL - part 3 - dna plugin Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Changed the DNA code to use the new slapi_ldap_init/slapi_ldap_bind code. Also changed the code to get the port number to use from the replication agreement. Added some more replication internal code knowledge to the DNA code (unfortunately). Platforms tested: Fedora 9 Flag Day: no Doc impact: yes https://bugzilla.redhat.com/attachment.cgi?id=322915&action=diff From rmeggins at redhat.com Mon Nov 10 20:35:27 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 10 Nov 2008 13:35:27 -0700 Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL - part 4 - pta, winsync Message-ID: <49189B0F.30507@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=469261 Resolves: bug 469261 Bug Description: Support server-to-server SASL - part 4 - pta, winsync Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Allow pass through auth (PTA) to use starttls. PTA uses the old style argv config params, so I just added an optional starttls (0, 1) to the end of the list, since there is currently no way to encode the startTLS extop in the LDAP URL. NOTE: adding support for true pass through auth for sasl or external cert auth will require a lot of work - not sure it's worth it - anyone other than console users can use chaining backend instead. For windows sync, I just ported the same slapi_ldap_init/slapi_ldap_bind changes made to regular replication to the windows specific code. The Windows code still needs the do_simple_bind function to check the windows password, but it is not used for server to server bind anymore. NOTE: Windows does support startTLS, but I did not test the SASL mechanisms with Windows. Platforms tested: Fedora 9 Flag Day: no Doc impact: yes https://bugzilla.redhat.com/attachment.cgi?id=323115&action=diff From hyc at symas.com Tue Nov 11 17:11:11 2008 From: hyc at symas.com (Howard Chu) Date: Tue, 11 Nov 2008 09:11:11 -0800 Subject: > Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL - part 4 - pta, winsync In-Reply-To: <20081111170041.3D5D661B4A9@hormel.redhat.com> References: <20081111170041.3D5D661B4A9@hormel.redhat.com> Message-ID: <4919BCAF.3000903@symas.com> > Date: Mon, 10 Nov 2008 13:35:27 -0700 > From: Rich Megginson > https://bugzilla.redhat.com/show_bug.cgi?id=469261 > Resolves: bug 469261 > Bug Description: Support server-to-server SASL - part 4 - pta, winsync > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: Allow pass through auth (PTA) to use starttls. PTA > uses the old style argv config params, so I just added an optional > starttls (0, 1) to the end of the list, since there is currently no way > to encode the startTLS extop in the LDAP URL. I recently added support to OpenLDAP's libldap for specifying StartTLS as an LDAP URL extension. It seems this was discussed on the IETF LDAPext group some time ago and then it died. Perhaps if you add a request to the discussion we can get this resurrected and standardized. IMO there's an obvious need for this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rmeggins at redhat.com Tue Nov 11 17:18:29 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Nov 2008 10:18:29 -0700 Subject: > Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL - part 4 - pta, winsync In-Reply-To: <4919BCAF.3000903@symas.com> References: <20081111170041.3D5D661B4A9@hormel.redhat.com> <4919BCAF.3000903@symas.com> Message-ID: <4919BE65.2000004@redhat.com> Howard Chu wrote: >> Date: Mon, 10 Nov 2008 13:35:27 -0700 >> From: Rich Megginson > >> https://bugzilla.redhat.com/show_bug.cgi?id=469261 >> Resolves: bug 469261 >> Bug Description: Support server-to-server SASL - part 4 - pta, winsync >> Reviewed by: ??? >> Files: see diff >> Branch: HEAD >> Fix Description: Allow pass through auth (PTA) to use starttls. PTA >> uses the old style argv config params, so I just added an optional >> starttls (0, 1) to the end of the list, since there is currently no way >> to encode the startTLS extop in the LDAP URL. > > I recently added support to OpenLDAP's libldap for specifying StartTLS > as an LDAP URL extension. It seems this was discussed on the IETF > LDAPext group some time ago and then it died. Yep, I saw that. > Perhaps if you add a request to the discussion we can get this > resurrected and standardized. Ok. > IMO there's an obvious need for this. Yes, agreed. From nkinder at redhat.com Thu Nov 13 17:48:07 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 13 Nov 2008 09:48:07 -0800 Subject: [Fedora-directory-devel] Please Review: (470918) replica_set_updatedn does not handle modifications of type ldap_add correctly Message-ID: <491C6857.4060505@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=470918 Resolves: bug 470918 Bug Description: The replica_set_updatedn() checks the type of modify operation that it is dealing with by checking if specific bits are set when the replica update DN attribute is being modified. The problem is that the value of LDAP_MOD_ADD is 0, so you can't use a simple bit check. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix is to check the value of the modify operation type instead of doing a simple bit check. We need to be careful to exclude the bit flag for LDAP_MOD_BVALUES since it could be set along with any of the modify op types. Platforms tested: Fedora 8 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=323481&action=diff From nkinder at redhat.com Thu Nov 13 21:36:32 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 13 Nov 2008 13:36:32 -0800 Subject: [Fedora-directory-devel] Please Review - Take 2: (470918) replica_set_updatedn does not handle modifications of type ldap_add correctly In-Reply-To: <491C6857.4060505@redhat.com> References: <491C6857.4060505@redhat.com> Message-ID: <491C9DE0.9030200@redhat.com> Nathan Kinder wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=470918 > Resolves: bug 470918 > Bug Description: The replica_set_updatedn() checks the type of modify > operation that > it is dealing with by checking if specific bits are set when the > replica update DN > attribute is being modified. The problem is that the value of > LDAP_MOD_ADD is 0, > so you can't use a simple bit check. > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: The fix is to check the value of the modify operation > type instead > of doing a simple bit check. We need to be careful to exclude the > bit flag for > LDAP_MOD_BVALUES since it could be set along with any of the modify > op types. Rich suggested that a convenience macro would be nice for checking the modify operation type, so I revised my previous fix to define new macros and to use them throughout the server. The link to the new diffs is below. > Platforms tested: Fedora 8 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/attachment.cgi?id=323481&action=diff https://bugzilla.redhat.com/attachment.cgi?id=323496&action=diff > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel From nkinder at redhat.com Fri Nov 14 01:27:04 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 13 Nov 2008 17:27:04 -0800 Subject: [Fedora-directory-devel] Please Review: (450046) changelog writes can hang due to leftover semaphore Message-ID: <491CD3E8.5050504@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=450046 esolves: bug 450046 Bug Description: The semaphore used by the changelog can be left around if the server doesn't exit cleanly. If the value happens to be at 0 when this happens, the server will be unable to write to the changelog the next time it is started. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: This fix makes the changelog code attempt to create the semaphore with exclusive access. If this fails due to the semaphore being left around from a previous unclean exit of the server, we delete the semaphore and re-create it. Platforms tested: Fedora 8 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=323522&action=diff From rmeggins at redhat.com Fri Nov 21 21:40:20 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 21 Nov 2008 14:40:20 -0700 Subject: [Fedora-directory-devel] Please review: Bug 469261 - Support server-to-server SASL - console replication changes Message-ID: <49272AC4.9010405@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=469261 Resolves: bug 469261 Bug Description: Support server-to-server SASL - console replication changes Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: This adds support for starttls, gssapi, and digest to the console for setting up replication agreements. 1) Instead of a checkbox for use ssl, I added 3 radio buttons - no ssl, regular ldaps, starttls - note: active directory supports starttls 2) To the ssl auth and simple auth radio buttons, I added gssapi and digest. The way the logic works is that gssapi is only allowed when using regular ldap, digest and simple bind are allowed always, ssl auth is only allowed with one of the ssl options. gssapi allows an empty bind dn and password, but digest and simple require a bind dn and password. NOTE: we do not support anything other than simple bind with active directory in the GUI I also changed the wording a little bit, and added tool tips (which will hopefully not be too annoying) I did not add additional checking e.g. the console cannot verify that kerberos is set up properly Platforms tested: RHEL5 Flag Day: no Doc impact: oh yes https://bugzilla.redhat.com/attachment.cgi?id=324349&action=diff From nkinder at redhat.com Fri Nov 21 22:14:52 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 21 Nov 2008 14:14:52 -0800 Subject: [Fedora-directory-devel] Please Review: (216522) password change extop doesn't respect local pwp Message-ID: <492732DC.2010406@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=216522 Resolves: bug 216522 Bug Description: The global password policy was always being used for password changes made with the password modify extended operation, even if a local policy was defined for the user/subtree. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The password modify extended operation ends up using an internal modify operation to perform the actual change. Unfortunately, we don't look for local password policies for internal operations. When choosing between the global and local password policies, we should always choose the local policy if one applies, regardless of the operation being internal or not. This fix simply makes us check for local policies for internal operations. A change was needed with where we fetch the policy when we are returning a result. We used to always fetch a policy, even though we only needed it when we were dealing with an error 49. This was causing us to infinitely recurse with the above change for fetching local policies for internal operations. The password policy code would perform an internal search for the local policy container, which would trigger the policy to be looked up again when we return the result for the internal operation. Since we only need to fetch the policy at result time for an error 49, I changed the code to only fetch the policy in this case. This case will never be true for an internal operation since we don't need to provide a bind DN or password. Platforms tested: Fedora 9 i686 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=324353&action=diff From nhosoi at redhat.com Mon Nov 24 17:22:52 2008 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 24 Nov 2008 09:22:52 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 472457] Specially crafted Server Side Sort crashes directory server or makes it unresponsive In-Reply-To: <200811221535.mAMFZCLc017429@bz-web1.app.phx.redhat.com> References: <200811221535.mAMFZCLc017429@bz-web1.app.phx.redhat.com> Message-ID: <492AE2EC.30704@redhat.com> Summary: Specially crafted Server Side Sort crashes directory server or makes it unresponsive https://bugzilla.redhat.com/show_bug.cgi?id=472457 [Problem Description] A test case posted by Andrey Ivanov could cause the directory server crash. A function to log the server side sorting sort_log_access had a bug to count the string size to be stored in the buffer. The code meant if the string length is less than or equal to the static buffer size, it uses the buffer. If it is longer, it allocates the enough size of space and use it. This is the sample of the string to log: SORT -sn;2.16.840.1.113730.3.3.2.18.1.6 -givenName;2.16.840.1.113730.3.3.2.18.1.6 (1944) The last "(1944)" is a count of candidates. The length was missing in the calculation for the string size. [Proposed patch] Created an attachment (id=324508) [details] cvs diff ldap/servers/slapd/back-ldbm/sort.c The cause of the problem was a buffer overflow. The length of the 2 sort specs "-sn;2.16.840.1.113730.3.3.2.18.1.6 -givenName;2.16.840.1.113730.3.3.2.18.1.6 " is just about the prepared buffer size, which is unfortunate since there is no space for the candidate size, e.g., "(1944)" being added later. By adding the "(1944)" to the static buffer, it caused buffer overflow and crashed your server. The code to check the length of the candidate size before calculating the buffer size is added. Thanks, --noriko -------------- 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: