those two patch fixes https://fedorahosted.org/sssd/ticket/1561 from the
sssd side. While testing I found that there is also a server side issue
which is tracked by https://fedorahosted.org/freeipa/ticket/3166 . As
long as the issue on the server is not solved this patch can be checked
by watching the logs and doing the following steps:
- stop sssd
- delete all ldb and memory mapped cache files
- start sssd
- call 'getent passwd UID_of_a_user_from_a_trusted_domain
Without the patch you should see in the log that the request is send via
ldapsearch to the IPA server, which the patch applied the request will
go to the extended operation to map the uid to a name.
If the SSSD domain is running with SSSDBG_TRACE_ALL, then we also set
Kerberos tracing with krb5_set_trace_filename.
There's one catch, though. The krb5_child and ldap_child logs are only
writable by root, but the krb5_child process drops privileges to the
user before priming his ccache. With this patch applied and debug_level
set to 10, the krb5_child process doesn't drop privileges..
I personally think that's fine, because running with debug_level 10
provides a LOT of debugging so it should only be configured for
debugging anyway. Also we don't drop privileges in other scenarios..
I could maybe add a new param to the child or add heuristics to drop
privileges after the debugging is set but that seemed like an over
engineering when this feature is only useful for hardcode debugging.
I noticed during the work on provider packaging that we still ship the
libsss_sudo.pc file and that we only ship the libsss_sudo.so library in
the -devel package. I think that's wrong. We might also want to move
libsss_sudo out of LDPATH in the future, but that's not really important
now (and it would require coordination with sudo).
I decided to keep libsss_sudo-devel around because it still contains the
The attached patch fixes the user-after-free crash I was seeing
The patch changes the subdomains discovery to use the tevent_req
style. Previously, the code violated several rules which made the code
very unreadable and led to memory hierarchy issues and use-after-free
See the commit message and ticket comments for more information.
This patch introduces one of the possible solutions, but I suggest to
consider actually changing memory hierarchy in responders.
Currently, the hierarchy looks like this:
main_ctx->specific_ctx->rctx, where specific_ctx is one of the pam, nss,
sudo, etc. contexts.
Does anybody know why it is not main_ctx->rctx->specific_ctx? This would
solve the issue as well and I personally think that it is more logical.