sssd-devel September 2015

sssd-devel@lists.fedorahosted.org

13 participants
90 discussions

[PATCHES] PAM: refactor pam_reply
by Pavel Reichl 27 Apr '16

27 Apr '16

Hello, 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. Thanks!

3 6

[PATCH] sudo: use "higher value wins" when ordering rules
by Pavel Březina 16 Feb '16

16 Feb '16

https://fedorahosted.org/sssd/ticket/2682 I think this option should stay undocumented since we want the users to use the correct sorting logic.

3 8

[PATCHES] BUILD: Speed up build of some tests
by Lukas Slebodnik 15 Feb '16

15 Feb '16

ehlo, 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) LS

2 3

[PATCHES] [sssd-1.11] Fixes suitable for latest release
by Lukas Slebodnik 10 Feb '16

10 Feb '16

ehlo, 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. LS

3 6

[PATCH] intg: Add more LDAP tests
by Nikolai Kondrashov 30 Jan '16

30 Jan '16

Hi everyone, Here is a patch set fixing some things in integration tests and adding more LDAP tests: * 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. Nick

6 43

[PATCH] Improve negcache with subdomains
by Jakub Hrozek 14 Jan '16

14 Jan '16

Hi, 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 tests.

2 5

[PATCH] util-tests: Initialize boolean variable to default value
by Lukas Slebodnik 14 Jan '16

14 Jan '16

ehlo, The boolean variable found_nss could be used uninitialized in test test_known_service if service "nss" would not be found. We would catch it with valgind. Simple patch is attached. LS

3 7

[PATCHES] cleanup task: Expire all memberof targets when removing user
by Michal Židek 14 Dec '15

14 Dec '15

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

4 14

[PATCH] CI: Enforce coverage make check failures
by Nikolai Kondrashov 09 Nov '15

09 Nov '15

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

2 4

Review of umask() in SSSD
by Petr Cech 05 Nov '15

05 Nov '15

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

3 17

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel September 2015