This patch backports commit 6fb75e297bf7fc83e3db1f5ae8560624656ef319 to
the 1.5.x branch. It makes one major change: 1.5.x does not have support
for deref/ASQ searches, so the deref lookup for hostgroups has been
replaced by parallel LDAP "base" searches.
I'm attaching two patches. One is the complete patch to backport, the
other is just an interdiff of the changes from Jan's original patch to
support the parallel lookups.
I'm still in the process of testing this patch, but I wanted to get it
out for review in the meantime.
I found this warning while reviewing Michal's transaction patch.
It was introduced in 9356e8f50436724e985d9a8f5d4f2bc0f5b837bc and it is
visible with the following CFLAGS:
-m64 -mtune=generic -O3 -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wall
-Wextra -Wno-sign-compare -Wno-unused-parameter
I just found this missing return while looking for a different issue.
I wonder why Coverity and friends didn't found it. Is there a way to
tell Coverity to handle talloc_free() similar for free()?
If the first group was cached when processing the nested group membership,
we would call tevent_req_done, effectivelly marking the whole nesting
level as done. That is wrong, we should only move to next group in the
same nesting level.
Attached are two patches. One that applies on the 1.5 branch and another
one that can be applied on top of both 1.8 and master.
I haven't yet figured out why we're not seeing the bug on master even
though the buggy code is there. Probably this issue is being shadowed b
another bug in the ghost users..I'll investigate more.
For now, I'm sending the patches for review to unblock the branches that
are affected by the bug.
Turning off sssd does not remove files in /var/lib/sss/mc. This allows
to respond on requests like
'id username' with sssd turned off. Is this behavior OK or is it a bug?
I think it is not very logical to
keep this files present. If someone turns off sssd, he probably wants to
turn off all services that
sssd provides. Or is there some other reason not to remove these files?
[PATCH 1/2] Do not try to remove the temp login file if already
write_selinux_string() would try to unlink the temporary file even after
it was renamed. Failure to unlink the file would not be fatal, but would
produce a confusing error message.
Also don't use "0" for the default fd number, that's reserved for stdin.
Using -1 is safer.
[PATCH 2/2] Only create the SELinux login file if there are mappings
on the server
In case there are no rules on the IPA server, we must simply avoid generating
the login file. That would make us fall back to the system-wide default
defined in /etc/selinux/targeted/seusers.
The IPA default must be only used if there *are* rules on the server,
but none matches.
This bug was probably introduced with the subdomain patches. The
problem was that sss_dp_get_domains_send() is called even for the local
provider. There are certainly many possible solutions of this issue. I
decided to modify sss_dp_issue_request() to call the callback
immediately if it is issued for local domain. This way, I believe, we
can avoid further problems with issuing request for local domains.