[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
14 years, 11 months
[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
14 years, 11 months
[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.
14 years, 11 months