Age | Commit message (Collapse) | Author | Files | Lines |
|
It is possible to enable/disable checking in LDB memberof plugin
whether it was built against the same version of LDB that is present
on the system. This feature is turned off by default
and enabled in Fedora/RHEL spec file.
https://fedorahosted.org/sssd/ticket/1813
|
|
When deleting a user we would fail the operation completely if the member
attribute was not found on one of the groups it was allegedly member of.
Failing in this case is unnecessary, and can cause issues.
Found trying to upgrade db versione (and failing) on one of my RHEL machines.
Also removed a tray \ in the companion function that removes ghost members,
that function needs no changes as it was already ignoring this kind of
failure.
|
|
src/ldb_modules/memberof.c: In function ‘mbof_get_ghost_from_parent_cb’:
src/ldb_modules/memberof.c:3085: warning: declaration of ‘dup’ shadows a global declaration
/usr/include/unistd.h:528: warning: shadowed declaration is here
src/ldb_modules/memberof.c: In function ‘mbof_inherited_mod’:
src/ldb_modules/memberof.c:3253: warning: declaration of ‘dup’ shadows a global declaration
/usr/include/unistd.h:528: warning: shadowed declaration is here
src/ldb_modules/memberof.c: In function ‘mbof_fill_vals_array’:
src/ldb_modules/memberof.c:3786: warning: declaration of ‘index’ shadows a global declaration
/usr/include/string.h:489: warning: shadowed declaration is here
|
|
https://fedorahosted.org/sssd/ticket/1703
|
|
https://fedorahosted.org/sssd/ticket/1652
It is possible to simply reset the list of ghost users to a different one
during a modify operation. It is also actually how we update entries that
are expired in the SSSD cache.
In this case, we must be careful and retain the ghost users that are not
native to the group we are processing but are rather inherited from child
groups. The intention of the replace operation after all is to set the
list of direct members of that group, not direct and indirect.
|
|
Similar to the add and delete operation, we also need to propagate the
changes of the ghost user attribute to the parent groups so that if a
nested group updates memberships, its parents also get the membership
updated.
|
|
This new function will be reused by the modify operation later
|
|
This new function is going to be reused by the modify operation
|
|
This will allow to process ghost users in a similar fashion
|
|
https://fedorahosted.org/sssd/ticket/1668
The memberof plugin did only expand the ghost users attribute to
parents when adding a nested group, but didn't implement the reverse
operation.
This bug resulted in users being reported as group members even
after the direct parent went away as the expanded ghost attributes were
never removed from the parent entry.
When a ghost entry is removed from a group, all its parent groups are
expired from the cache by setting the expire timestamp to 1. Doing so
would force the SSSD to re-read the group next time it is requested in
order to make sure its members are really up-to-date.
|
|
This macro is already available in util/util.h which is expicitly included
in this file.
|
|
When a nested group with ghost users is added, its ghost attribute should
propagate within the nested group structure much like the memberuid
attribute. Unlike the memberuid attribute, the ghost attribute is only
semi-managed by the memberof plugin and added manually to the original
entry.
This bug caused LDB errors saying that attribute or value already exists
when a group with a ghost user was added to the hierarchy as groups were
updated with an attribute they already had.
|
|
|
|
Large memberof delete operations can cause quite a number of searches
and the results are attached to a delop operation structure.
Make sure we free this payload once the operation is done and these
results are not used anymore so that we get a smaller total memory footprint.
|
|
We were skipping the check on the next value in the added list when a match
was found for the currentr value being checked.
|
|
|
|
|
|
|
|
Some assignments deleted, two return value inspections were
added.
Ticket: #589
|
|
With complex hierarchies it could happen that the group just deleted was
re-added by mistake to the list of groups a user is member of, causing the user
to have a stray memberof value in its entry.
|
|
Also update BUILD.txt
|