https://bugzilla.redhat.com/show_bug.cgi?id=439628
Resolves: bug 439628
Bug Description: When deleting a member value from a group, the member
entry has the proper memberOf value removed, but a check is not made
to see if the entry is still a member of parent groups through some
other grouping path first. This results in an inconsistency between
member and memberOf attribute values.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The fix is to check if an entry is an indirect group
member before removing the memberOf attribute value form the entry.
I had to add a few new helper functions to perform this check. The new
utility functions allow you to check if a specific entry is a member of
a specific group by looking at member values only. There is a function
for checking if the entry is a direct member, and one that will check
for direct or indirect membership. Both of these functions will not
modify the entry, which is what was lacking in the previous code. These
utility functions required a recursive function underneath to trace
through indirect memberships. This recursive function will detect group
loopings to ensure it doesn't endlessly recurse.
I also did some refactoring and commenting of existing code to make
things
more clear. These changes have been checked for memory leaks with
valgrind,
and I've also checked for regressions of other recently fixed bugs
in the
memberOf plug-in.
Platforms tested: RHEL5.1 x86_64
Flag Day: No.
Doc impact: None.
https://bugzilla.redhat.com/attachment.cgi?id=302951&action=diff
Hi!
I've read the http://directory.fedoraproject.org/wiki/MemberOf_Plugin
article and one thing striked me:
The functionality that memberOf provides is very similar to that
provided by the Roles plugin
(http://directory.fedoraproject.org/wiki/Architecture#Roles)
The Roles plugin, however, for filtered roles uses virtual attributes,
and seems to work fine with replication (note: I didn't test it yet in
my replicated environment).
MemberOf, OTOH, uses "materialized dynamic attributes" approach similar
to discussed on OpenLDAP mailing list WRT dynamic groups/autogroup
contrib module.
I recommend reading the discussion, since it may contain some
conclusions that could be useful in implementing memberOf:
http://www.openldap.org/lists/openldap-software/200708/msg00255.html ,
http://www.openldap.org/lists/openldap-software/200708/msg00280.html ,
http://www.openldap.org/lists/openldap-devel/200708/msg00127.html ,
http://www.openldap.org/lists/openldap-devel/200708/msg00176.html ,
http://www.openldap.org/lists/openldap-devel/200709/msg00069.html ,
http://www.openldap.org/lists/openldap-devel/200709/msg00074.html
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
--
Aleksander Adamowski
Administrator systemów korporacyjnych; Instruktor
Altkom Akademia S.A. http://www.altkom.pl
Warszawa, ul. Chłodna 51
tel. brak
kom. +48 601-318-080
Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is prohibited.
If you received this message by mistake, please contact the sender immediately and delete all copies of this message.
https://bugzilla.redhat.com/show_bug.cgi?id=439829
Resolves: bug 439829
Bug Description: simple password auth fails using NSS 3.11.99 or later
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The new softokn in NSS 3.11.99 and later requires that
the server calls NSS_Init() after forking, but before detaching from the
controlling terminal. In fact, this was always a requirement, but the
softokn in older NSS allow it. However, it's possible that some
hardware crypto devices do not allow this and may not work with older
directory servers. The fix is to move the nss/ssl initialization so
that it can be called at the right point, or from other points in cases
where the server does not fork (e.g. db2ldif).
Platforms tested: Fedora 9 i386, RHEL5 x86_64
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=300273&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=440474
Resolves: bug 440474
Bug Description: A number of memory leaks in the memberOf plug-in occur
during
various operations on member attributes. These leaks were discovered
using
valgrind to run ns-slapd.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: We were allocating a Slapi_Mods in the modify callback
and never
calling slapi_mods_free() would cause a double free. This is because
we are
initialing the Slapi_Mods by passing in the LDAPMod array from
SLAPI_MODIFY_MODS
in the pblock. This will make slapi_mods_free() do a free of the
LDAPMod elements,
but do_modify() is responsible for freeing the LDAPMod array in the
pblock. The
solution is to initialize the Slapi_Mods by reference so
slapi_mods_free() doesn't
try to free the LDAPMod array.
There were 4 places where we were allocating a Slapi_Entry by calling
slapi_search_internal_get_entry(), but never freeing the entry when we
were
finished with it.
We were allocating two Slapi_Value arrays with slapi_ch_malloc(), but were
never calling slapi_ch_free() when we were finished.
Platforms tested: RHEL5.1 x86_64
Flag Day: No.
Doc impact: None.
https://bugzilla.redhat.com/attachment.cgi?id=300297&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=439829
Resolves: bug 439829
Bug Description: simple password auth fails using NSS 3.11.99 or later
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The new softokn in NSS 3.11.99 and later requires that
the server calls NSS_Init() after forking, but before detaching from the
controlling terminal. In fact, this was always a requirement, but the
softokn in older NSS allow it. However, it's possible that some
hardware crypto devices do not allow this and may not work with older
directory servers. The fix is to move the nss/ssl initialization so
that it can be called at the right point, or from other points in cases
where the server does not fork (e.g. db2ldif).
Platforms tested: Fedora 9 i386, RHEL5 x86_64
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=300273&action=diff