December 2008 - 389-devel - Fedora Mailing-Lists

[Fedora-directory-devel] Please Review: (474621) Adding a user with nsuniqueid in the RDN creates an illegal entry

by Nathan Kinder

https://bugzilla.redhat.com/show_bug.cgi?id=474621 Resolves: bug 474621 Bug Description: If you add an entry using a create attribute in the RDN (such as nsuniqueid), the entry will be added, but the value used in the RDN will not exist in the entry. The same issue occurs with performing a MODRDN operation using a created attribute in the new RDN. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The fix checks if the common created attributes are used as the RDN for both ADD and MODRDN operations. We disallow using nsuniqueid, creatorsName, modifiersName, modifiedTimestamp, and createTimestamp in the RDN for an external ADD operation. For a MODRDN, we disallow the same attributes in the new RDN with the exception of nsuniqueid. We want to allow nsuniqueid in the RDN from internal operations for replication conflict entries. The client will receive an LDAP_INVALID_DN_SYNTAX result if they violate the above rules. Platforms tested: F9 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none https://bugzilla.redhat.com/attachment.cgi?id=327773&action=diff

15 years, 4 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 472092 - (DSGW_passwd_corrupt) DSGW password corruption

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=472092 Resolves: bug 472092 Bug Description: DSGW password corruption Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: 1) By default, all of the get/post parameters have the html entities escaped, so we can be sure that they are displayed to the user escaped, to avoid XSS issues. However, values sent to LDAP must be unescaped. The doauth code is used to authenticate directory manager and ordinary users, so we have to unescape the password explicitly there. The domodify code is used when data is added or modified in the directory server. It's easier to just fix all of the values before sending to the directory server. 2) The entity code has been moved to adminutil, so use the adminutil functions instead of the dsgw functions. This will require adminutil 1.1.8. 3) Clean up various compiler warnings. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=327686&action=diff

15 years, 4 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 471681 - DSGW authenticate multi-result hyperlinks broken

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=471681 Resolves: bug 471681 Bug Description: DSGW authenticate multi-result hyperlinks broken Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: 1) The quoting was a bit off. The DSGW code adds double quotes at the beginning and end of the javascript. We have to use %22 to have DSGW emit double quotes in the right places where other double quotes are needed. 2) If you are attempting to auth as a real user, and you have password policy on such that the user must change the password after reset, and you are using a binddn instead of the default anon, the auth screen would not prompt you for your old password, because it thought you were already bound as the binddn. The binddn is not a real user in this case, and so should not be considered when testing for "bound". Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=327681&action=diff

15 years, 4 months

1
0
0 / 0

[Fedora-directory-devel] handling forward-only links, DN+Binary and DN+String

by Andrew Bartlett

Having thought I got to the bottom of extended DN behaviour, I've come across more challenges, that I would like thoughts on. Handling renames of one-way links: OpenLDAP already does this, but Samba needs some help here (as we try to infer the rename from the presence of backlinks, but for one-way links, how should we know we are being linked to?) Handling of DN+Binary and DN+String one-way links. For example, wellKnownObjects: B:32:22b70c67d56e4efb91e9300fca3dc1aa:CN=ForeignSecurityPrincipals,DC=samba,DC=org This is a 'DN+Binary' syntax attribute (for resolving well known GUIDs into a DN), and must therefore follow when the well known target renames. MS-ADTS 3.1.1.1.6 specifies the behaviour. The challenge I see here is that I really do need an additional syntax in OpenLDAP. If I map this to just a binary string (as I do now), then the rename will not follow though. If I map it to a DN (as I had tried in the past), then the syntax is invalid. Is it entirely unreasonable to add an additional syntax? This is a bit of a 'hit and run' question, as I won't be able to carry on the discussion during Christmas/New Year, but any thoughts would be most welcome. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.

15 years, 4 months

2
1
0 / 0

[Fedora-directory-devel] Please review: Bug 476891 - Replication: Server to Server Connection Error: SASL(-1): generic failure: All-whitespace username.

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=476891 Resolves: bug 476891 Bug Description: Replication: Server to Server Connection Error: SASL(-1): generic failure: All-whitespace username. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: My earlier fix for this bug broke GSSAPI - it would cause the username and authid to only be freed under certain conditions e.g. if the krb creds were still valid, the code would not free the username and authid, so they would be passed via SASL instead of the principal name. This fix just makes sure username and authid are always freed, under all circumstances. Platforms tested: RHEL5, Fedora 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=327485&action=diff

15 years, 4 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 476891 - Replication: Server to Server Connection Error: SASL(-1): generic failure: All-whitespace username.

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=476891 Resolves: bug 476891 Bug Description: Replication: Server to Server Connection Error: SASL(-1): generic failure: All-whitespace username. Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: 1) SASL/DIGEST-MD5 needs both username and authid 2) The username and authid in this context are always a bind DN - they must have the "dn:" prefix in order for the SASL mapping to work 3) gssapi (kerberos) sets both username and authid to NULL Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=327280&action=diff

15 years, 4 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 179184 - Advanced Properties window sorts by attribute name not "friendly name"

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=179184 Resolves: bug 179184 Bug Description: Advanced Properties window sorts by attribute name not "friendly name" Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Just call the showAllAttributes method at the end of the ctor. This method will sort the list in the correct order. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=327157&action=diff

15 years, 4 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 198090 - ACI editor table sort problem

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=198090 Resolves: bug 198090 Bug Description: ACI editor table sort problem Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The main problem was that the Table Model code was not checking the type of the model change event, and was just unconditionally resetting/initializing the internal indexes array every time the checkbox was checked. This caused the table to revert back to the original order every time a checkbox was checked on or off. The only events which should cause the indexes to be reset/initialized are the INSERT and DELETE types, not the UPDATE type. There were also some problems with setting up the initial model, and I cleaned up some bogus code. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=327150&action=diff

15 years, 4 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 179193 - Replication UI most of the time don't return consumer initialization error

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=179193 Resolves: bug 179193 Bug Description: Replication UI most of the time don't return consumer initialization error Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Just added a 3 second sleep after telling the server to perform the consumer init. This seems to give the server time enough to attempt the init, fail, and set an appropriate error code. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=327021&action=diff

15 years, 4 months

1
0
0 / 0

[Fedora-directory-devel] Please review: Bug 426439 - Unable to load CRL file for a DS instance - when its placed under /etc/dirsrv/slapd-INSTANCE

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=426439 Resolves: bug 426439 Bug Description: Unable to load CRL file for a DS instance - when its placed under /etc/dirsrv/slapd-INSTANCE Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The main problem was that it was not using the getSecurityDir function to get the security dir based on the SIE passed in. This function is called in main after getting the SIE. I changed the code to set this value in a static variable that can be used throughout the program. In addition, I found and fixed some other bugs related to CRL handling: 1) The code did not work with ASCII CRLs generated by newer versions of crlutil which use the BEGIN CRL header. I added processing for that header type. 2) The code did not handle date/time in generalized time format. I added code to format the date/time based on the type of date/time stored in the CRL. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=327005&action=diff

15 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel December 2008