please see attached patch for ticket
Probably in some part of the code we call the
function sss_get_domain_name with FQDN. We use
regular expression to check if it is the case and
if not (and regex is configured not to accept
non FQDN) than this function fails to construct the
requested name in the output.
Since the sss_parse_name is here only used to detect
if the name contains domain portion, it is safe
to assume it does not contain it if regular
expression has failed to match anything.
with this patch SSSD can switch to a new view at startup. There is a
todo in the third patch. Currently the user and group entries are only
invalidated so that the new view/override data is checked at the next
request for the given object. Additionally we might want to start a
background task with refreshes the existing entries in the cache
unconditionally. But this might result in unwanted network peaks during
startup. So I left the implementation for a later patch, if this is
When I was working on https://fedorahosted.org/sssd/ticket/2501 I
noticed several things I didn't like. Most importnantly, the checks were
done on several places -- I think security decisions should be done at
one place only ideally so any changes don't miss other calls.
I'll be sending other patches soon, but this one is important to get in
In particular, the issue would hit when you try to authenticate as a
user from a domain that is second on the list. In pam_dom_forwarder, we
might change the pd->dom pointer, bypassing the check done previously.
Additionally, the restricted domains are only checked if the process is
trusted. Shall I split that to a new patch?
Please also let me know if the performance implication outlined in the
ticket seems like an important one.
this patch provides a fix for https://fedorahosted.org/sssd/ticket/2473.
I tired to not restrict it to the localauth plugin but make it possible
to easily add other snippets in future.
Currently I don't do any specific checks on the given path because if it
is really changed to some other path by the admin we cannot expected and
permissions or ownerships. If you think that some checks are need I'd be
happy to add them.
The first patch fixes an issues in the autoconf/automake machinery which
I came across while testing the patch.
The commit message is quite self explanatory.
The attached file "test.c" is a simple reproducer for crash.
It shoudl be executed as user from sssd becuasde it call getuid() or
getgid(). In infinite loop, the program calls getpwuid_r() or getgrgid_r()
in threads (count of threads is specified from command line).
While test program is running you can call sss_cache -E (-U -G) to invalidate
cache ( or better "while true; do sss_cache -G; usleep 100; done")
There should not be crash with attached patch, but it isn't 100% reproducer
because it's difficult to reproduce race condition. I was able to find problem
in my code even thout the program didn't crashed for 5 minutes.
You can also test that memory cahce is used after reinitialisation.
strace -p `pgrep test_prog` -f -e trace=sendto
BTW: unit test from mail  will pass with small change.
diff --git a/src/tests/cmocka/test_mc_client.c b/src/tests/cmocka/test_mc_client.c
index 4347cce..99d922a 100644
@@ -262,7 +262,7 @@ static void test_client_reinit_race_condition(void **state)
- sss_will_return_always(__wrap_sss_nss_check_header, 3);
+ /* sss_will_return_always(__wrap_sss_nss_check_header, 3); */
ret = pthread_barrier_init(&barr, NULL, THREADS_COUNT);
I was testing with a subdomain user who was a member of IPA group and
found out the extdom plugin didn't handle the IPA group well, because
the group name wasn't qualified.
Is handling this situation on the client (as opposed to changing the
server so that all group names are qualified) the right approach?