Sumit wrote me yesterday, that some krb5 functions in
get_ccache_name_by_principal needn't be available in older version of libkrb5.
We noticed that this function is very similar to another function
get_ccache_for_princ and there was used conditional build.
Refactoring patch is attached.
Now the output looks like:
$ su test-user
Password expired. Change your password now.
Retype new password:
Password change failed. Please make sure the password meets the
su: incorrect password
Attached patches should fix https://fedorahosted.org/sssd/ticket/1980
The first patch adds check after sysdb_getnetgr. If sysdb_getnetgr returns more
result than 1, sssd will return error. sysdb_getpwnam has already had
The second patch removes function call sss_cmd_done inside of check_cache,
because function is sss_cmd_done is called in parent functions.
This was a reason of sssd crash.
How to reproduce this crash.
1.Add Netgroup to sysdb cache with base cn=Netgroups,cn=<domain>,cn=sysdb
This netgroup should have the same attribute (name or nameAlias or memberOf)
as another netgroup.
2. call sudo with user, which is member of ^^^ netgroup.
Those patches fix only sssd crash, but we should find out:
Why were those netgroups stored in sysdb.
It seems that some linkers have problem with wrong order of libraries.
This commit only change order.
Attached patch should fix next issue:
Library libsss_crypt.so is used in linking process, but there are
It seems that I changed order of libraries after rewriting link_all_deplibs
patch to use automake variable SSSD_INTERNAL_LTLIBS. I only tested
new patch with patched version of libtool on fedora.
libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Werror-implicit-function-declaration -fno-strict-aliasing -std=gnu99 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/samba-4.0 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -o .libs/sss_ssh_authorizedkeys src/sss_client/sss_ssh_authorizedkeys-common.o src/sss_client/ssh/sss_ssh_authorizedkeys-sss_ssh_client.o src/sss_client/ssh/sss_ssh_authorizedkeys-sss_ssh_authorizedkeys.o -lpthread -ltalloc /usr/lib/x86_64-linux-gnu/libpopt.so ./.libs/libsss_crypt.so ./.libs/libsss_debug.so ./.libs/libsss_child.so ./.libs/libsss_util.so -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/sssd
./.libs/libsss_util.so: undefined reference to `sss_base64_decode'
./.libs/libsss_util.so: undefined reference to `s3crypt_gen_salt'
./.libs/libsss_util.so: undefined reference to `sss_base64_encode'
./.libs/libsss_util.so: undefined reference to `s3crypt_sha512'
collect2: error: ld returned 1 exit status
The problem here wasn't in returned error code, but in faultly read DBUS
message, due to condition in sss_authtok_set_string.
When password is empty, it passes 0 as length, which is misinterpreted,
and the function tries to determine the length of string by itself,
reaching over boundaries of authtok string.
trac issue: https://fedorahosted.org/sssd/ticket/1814
Patch is attached
Associate Software Engineer
Identity Management - SSSD
Red Hat Czech
Unfortunately, the reported did not provide logs from the time of crash.
The backtrace only says that it occurred in nsupdate_child_handler() but
I'm very confident that the root cause was that the dyndns update
The first patch fixes dyndns unit tests to actually reveal the crash.
Cooler solution would be to use tevent_loop_wait(), but it contains an
issue due to which it is not possible. This issue was reported on Samba
Second patch will fix the crash.
What is the difference between child_sig_handler() which uses context
suffixed with _old and sss_sigchld_init()? Would it make sense to update
the code to the new sigchld handler?