While checking if our custom signal handlers properly handle errno, I
stumbled on a few cleanups, they are attached.
turns out our few signal hanlders are errno safe, and tevent signal
handling function is also fine.
Simo Sorce * Red Hat, Inc * New York
yet another warning from clang static analyser.
sss_krb5_princ_realm set output parameter realm to NULL and len to 0
in case of failure. Clang static analysers repoted warning
"Null pointer passed as an argument to a 'nonnull' parameter"
in function match_principal. It was possible, that realm_name with value NULL
could be used in strncmp.
Function sss_krb5_princ_realm is used on other places for printing(formatting)
realm_name and NULL can be safely used as a argument for printf-like
Patch is attached.
Using sssd, for a long time, I have come across with a problem recently,
which I would like to solve with your help.
I provide centralized authentication and authorization service for a huge
heterogeneous network. And in my case it would be "nice and easy" if sssd
used only shells(5). I believe this mechanism is sufficient for
identification of an allowed shell.
I take a liberty to offer you this tiny patch, which will let use wildcard
(*) in param allowed_shells in sssd.conf
What do you think about it?
attached patch is the first of many to solve
"The return codes of various sysdb operations differ. Some search
operations would return ENOENT if they don't find a matching object some
would return EOK but an empty result list."
I think it would be best if in case that no results were found both
ENOENT value and 'properly' empty list were returned.
Thank for opinions or/and review.
this patch replaces strerror with sss_strerror on some places.
I think it would be OK to use always sss_strerror, but to keep
the patch relatively small I left strerror on places where
we directly print value of errno or return value of some third
party functions that do not (and never will) return our specific
Patch is attached. It may look big (111 files changed), but
there are only few insertions and deletions in each.
the attached two patches are not strictly related to tokenGroups
processing, but it's very easy to reproduce the problem that way. The
issue is only confusing DEBUG messages, but it has already cost me
several hours in processing logs from an SSSD user, so I think a fix is
due, at least for master.
See the patches and the commit messages for more details.
please see attached patch.
This patch was previously written for BZ 1059423. But it now seems that
more detailed logging information is generally useful for issues that
are emerging from this area lately.