[PATCHES] cleanup task: Expire all memberof targets when removing user
by Michal Židek
Hi,
see the attached patches for ticket
https://fedorahosted.org/sssd/ticket/2676
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
inconsistent results.
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).
Thanks,
Michal
--
Senior Principal Intern
8 years, 4 months
[PATCHSET] intg: sss_override
by Pavel Reichl
Hello,
please see first version of patch set. Please consider this to be work in progress.
The test 'test_local_override_group' fails, there seem to be a bug in sss_override. Pavel is working on the patch. He kindly provided me with early version of patch and it fixed the test.
Currently also test for #2790 test_local_overrides_regr_2790() is failing which is probably just bug in the test itself.
Thanks for any comments.
8 years, 5 months
[PATCH] TEST: recent_valid filter testing
by Petr Cech
Hi,
there is WiP attached. I removed some tests like this one some time ago.
They fail really often and we decided that the test logic was corrupted.
Now I am trying get it back to the codebase.
There is some kind of cmocka magic around data provider. I think it
creates test_user_1 during creation of filter.
In case of this type of tests, we need two users, one stored before
filter request and one stored after filter request. There is a special
type of filter which has time parameter which it search from. So the
filter returns only one user.
If this concept is right, I will send whole patch.
Regards
Petr
PS: I applied my patch after 000*-cache_req_*. Those patches are on list.
8 years, 5 months
[PATCH] CI: Enforce coverage make check failures
by Nikolai Kondrashov
Hi everyone,
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
fixed first.
Nick
8 years, 5 months
Review of umask() in SSSD
by Petr Cech
Hi,
I am reviewing umask() in our code according to
https://fedorahosted.org/sssd/ticket/2424
There are many use like umask(DFL_RSP_UMASK):
src/responder/autofs/autofssrv.c:223
src/responder/ifp/ifpsrv.c:401
src/responder/nss/nsssrv.c:589
src/responder/pac/pacsrv.c:232
src/responder/pam/pamsrv.c:369
src/responder/ssh/sshsrv.c:209
src/responder/sudo/sudosrv.c:215
where DFL_RSP_UMASK is defined as 0177.
There are another three use of umask 0177:
src/confdb/confdb.c:662
src/util/debug.c:365
src/util/server.c:495
And then I see many use of umask 077:
src/p11_child/p11_child_nss.c:485
src/providers/krb5/krb5_child.c:723
src/tests/check_and_open-tests.c:51
src/tests/debug-tests.c:136
src/tests/debug-tests.c:276
src/tests/util-tests.c:596
src/util/domain_info_utils.c:312
src/util/domain_info_utils.c:562
src/tools/tools_util.c:503
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:
src/responder/common/responder_common.c:693
src/responder/pam/pamsrv.c:399
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?
Regards
Petr
8 years, 5 months
[PATCH] LDAP: Fix leak of file descriptors
by Lukas Slebodnik
ehlo,
Details are in commit message. BTW it would be good to have at least two
reviews.
Reproducer which I used for https://fedorahosted.org/sssd/ticket/2792:
Setup:
* two active directories with sites; so sometimes sssd connect to server A
and sometims to server B.
* block connection to one server
[root@host sssd]# iptables -n -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- 0.0.0.0/0 10.12.0.158 tcp dpt:389
* force sssd to go offline (-USR1) and online (-USR2)
You might be able to reproduce ti even with plan LDAP.
It might help if set value of options that
dns_resolver_timeout < ldap_network_timeout
Do you have an idea how to test such fd leak?
(either using cmocka or integration tests)
LS
8 years, 5 months