please see attached patch set which contains some refactoring which is
in my opinion quite safe. It doesn't touch the recursive call of
pam_reply() as I think that changing that would be more risky change.
Attached patches reduce count of compiled ".c" files
from 935 -> 815 (almost 9%). This reduction is achieved
in deduplication of compiling "*.c" files in tests.
BTW the tests were compiled 4 times in our CI script.
* make tests
* mock build
* make distcheck
* code coverage
The result saving will not be 9% of time due to parallel build
but it still worth. (and Makefile.am is simpler)
We have 19 patches in 1.11 branch on top of latest release (1.11.7)
I went through bugs filed against 1.11 branch and filter
crashes and the most important bugs.
Attached are cherrry-picked patches from 1.12/master
So we can release the latest 1.11 version. It will be just a bug-fix release.
So some conservative distribution can use it or in another words.
we don't want have 1.11 branch neither in unreleased not in unclosed state :-)
BTW I test packages with LDAP KRB5 and AD test. Of course there are any
regressions because it is a bug fix only release.
Here is a patch set fixing some things in integration tests and adding more
* Adding/removing a user/group/membership with rfc2307(bis) schema.
* Filtering users/groups with rfc2307(bis) schema.
* The effect of override_homedir option.
* The effect of fallback_homedir option.
* The effect of override_shell option.
* The effect of shell_fallback option.
* The effect of default_shell option.
* The effect of vetoed_shells option.
These are pretty basic, but I think they're good for the start.
Suggestions for more tests are welcome :)
NOTE: These still break test_memory_cache.py as seen in the attached log file.
We need to figure out why and do something with it. Otherwise, the
tests work fine.
I noticed this bug while working on the SSH fix with
default_domain_suffix. It turns out our filter_users/filter_groups don't
work well in this scenario, which might have effect on the server load
even. Attached are patches that re-initialize negcache with filter_lists
contents after the subdomains are (re)discovered. All patches have
see the attached patches for ticket
Removing the user during cleanup task completely
removes that user from local database, so that
user is no longer part of any group in sysdb.
Such user may, or may not have been removed from
LDAP so the only way to figure out is check
on the next refresh otherwise we may get
The third patch adds integration test for this
Apply and run the intgcheck without the first 2
patches to see the failed test (you will also see that
all the tests after this failed one will end with
errors as well, that is probably due to incomplete
clean up after the ldap tests and I do not intend to
solve this as part of this patchset but will
investigate it later).
Senior Principal Intern
The attached patch enforces make check failures for the CI coverage build, so
we can catch more test failures.
I think this should also be applied onto sssd-1-12.
NOTE: CI won't pass with this patch ATM, as test_ipa_subdom_server needs to be
I am reviewing umask() in our code according to
There are many use like umask(DFL_RSP_UMASK):
where DFL_RSP_UMASK is defined as 0177.
There are another three use of umask 0177:
And then I see many use of umask 077:
I would like to ask you if we would like to use 0077 or 0177 as our very
restrictive mask. I see that our code is not consistent on this
question. I know the difference is small, but it is.
Then we have some unsecure use:
src/providers/ipa/selinux_child.c:154: umask = 0
src/providers/krb5/krb5_ccache.c:188: umask = 0000
src/responder/nss/nsssrv_mmap_cache.c:1121: umask = 0022
but I think there is reason for it.
And the last one is at src/responder/common/responder_common.c:561:
int create_pipe_fd(const char *sock_name, int *_fd, mode_t umaskval)
We use it secure (0177) at:
And not so secure:
src/responder/common/responder_common.c:670 umask = 0111
src/responder/pam/pamsrv.c:391 umask = 0111
src/tests/cwrap/test_responder_common.c:173 umask = 0111
src/tests/cwrap/test_responder_common.c:179 umask = 0000
So, what could I do? Maybe we could have only one very secure umask and
maybe we could have CONSTANT for every use of umask. Any another ideas?