The conversion to the tevent_req style introduced numerous bugs
related to memory management of the various client requests. In
some circumstances, this could cause memory corruption and
segmentation faults in the NSS responder. This patch makes the
1) Rename the internal lookup from subreq to sidereq, to indicate
that it is not a sub-request of the current lookup (and therefore
is not canceled if the current request is).
2) Change the handling of the callback loops since they call
tevent_req_[done|error], which results in them being freed (and
therefore removed from the cb_list. This was the source of the
memory corruption that would occasionally result in dereferencing
an unreadable request.
3) Remove the unnecessary sss_dp_get_account_int_recv() function
and change sss_dp_get_account_done() so that it only frees the
sidereq. All of the waiting processes have already been signaled
with the final results from sss_dp_get_account_int_done()
Some NSS maps such as 'services' require more values to be passed
to the data provider than just the name or ID. In these cases, we
will amend an optional component to filter value to pass to the
data provider backend.
I'm sending this patch early since I know it's likely to impact work
being done in the SUDO and AutoFS responders.
I noticed that we never marked the internal account request as done so
the internal _recv function was never called and we would never free the
internal tevent_req structure. That means the responder_ctx would grow
The attached patch marks the internal request as done when all the
callbacks are handled. The outside account_done function is then only
called for the request that triggered DP lookup and the internal request
When I did sssd + openLDAP tests I found if remove nisNetgroupTriple or
memberNisNetgroup attribute, sssd did not reflected the changed,
"getent netgroup <group_name>" return unchanged result.
Timeout have been set and it works as exception.
I found when save user to local database, it will check missing attrs,
if lost then remove them, but when save group info to local database
sssd did not check this at all, any idea for this?
I have a case where a customer would like to authenticate users from two
different AD domains. Since IPA (currently) can't sync with multiple AD
domains, I was thinking of setting up two independent IPA servers that
sync with one AD each and then configure the clients with multiple sssd
authentication domains to authenticate users from both IPA:s.
Would this work? Does anyone foresee any difficulties?