May 2018 - sssd-devel - Fedora mailing-lists

[sssd PR#175][opened] Add module for starting services
by lslebodn 22 Nov '21

22 Nov '21

URL: https://github.com/SSSD/sssd/pull/175 Author: lslebodn Title: #175: Add module for starting services Action: opened PR body: """ This is a WIP version of reducing code duplication in our cwrap integration tests. I am still not sure whether we should also reuse function `create_sssd_fixture`. And if yes; then probably in different nodule then `services` And comments are welcome. BTW I wrote patches few weeks ago; therefore new tests are not converted. I am just sending patches to get some feedback. Site effect of this patches is that tests are cca 20% faster (IIRC) """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/175/head:pr175 git checkout pr175

5 5

[sssd PR#269][opened] Add support for ActiveDirectory's logonHours restrictions
by NWilson 03 Sep '20

03 Sep '20

URL: https://github.com/SSSD/sssd/pull/269 Author: NWilson Title: #269: Add support for ActiveDirectory's logonHours restrictions Action: opened PR body: """ This is a straightforward patch for denying access to a user when the user is not permitted to access their account due to logonHours restrictions. This matches the default behaviour for domain-joined Windows machines. When outside the logonHours, all types of authentication are denied (password/Kerberos/certificate) - so it is appropriate to put this check inside the PAM "account" rules. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/269/head:pr269 git checkout pr269

9 30

[sssd PR#578][opened] proxy: proxy_child hardening
by amitkumar50 10 Aug '20

10 Aug '20

URL: https://github.com/SSSD/sssd/pull/578 Author: amitkumar50 Title: #578: proxy: proxy_child hardening Action: opened PR body: """ proxy_child will call chdir("/"), umask(022) and reset the environment with clearenv(). The --domain argument to be sanitized. Resolves: https://pagure.io/SSSD/sssd/issue/2689 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/578/head:pr578 git checkout pr578

5 14

[sssd PR#132][opened] Add "Wants=" to sssd unit and avoid PAC responder to be always running
by fidencio 02 Jan '20

02 Jan '20

URL: https://github.com/SSSD/sssd/pull/132 Author: fidencio Title: #132: Add "Wants=" to sssd unit and avoid PAC responder to be always running Action: opened PR body: """ The first patch changes the current logic of having the services' sockets disabled by default as it adds a "Wants=" to the sssd unit file, making all the services' sockets enabled by the moment sssd service is enabled. The second patch takes advantage of the first patch and avoids running PAC responder in case its socket is active, leaving the service to be socket-activated when needed. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/132/head:pr132 git checkout pr132

3 40

[sssd PR#558][opened] WIP: Add a test for sss_nss_getgrouplist_timeout and fix invalidating the initgroups cache
by jhrozek 04 Nov '19

04 Nov '19

URL: https://github.com/SSSD/sssd/pull/558 Author: jhrozek Title: #558: WIP: Add a test for sss_nss_getgrouplist_timeout and fix invalidating the initgroups cache Action: opened PR body: """ This is a WIP on adding tests for the sss_nss_ex interface. I covered only the sss_nss_getgrouplist_timeout function so far. I'm submitting the PR already in this state to get some feedback if this coverage is enough and the other functions can be covered similarly or if there is some issue with this approach. Also, I found a bug in invalidating the initgroups memory cache, that's the first of the two patches. Here I'm really not sure if the fix is even how the issue should be fixed, so I just hacked something up, even without allocation checks etc. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/558/head:pr558 git checkout pr558

3 10

[sssd PR#457][opened] ipa: Removal of umask(0) in selinux_child
by amitkumar50 30 Oct '19

30 Oct '19

URL: https://github.com/SSSD/sssd/pull/457 Author: amitkumar50 Title: #457: ipa: Removal of umask(0) in selinux_child Action: opened PR body: """ Code for calling umask(0) was added to address bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1186422. Now this bugzilla is fixed, removing the workaround. Resolves: https://pagure.io/SSSD/sssd/issue/3583 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/457/head:pr457 git checkout pr457

11 27

[sssd PR#390][opened] NSS: Add option to disable memcache
by mzidek-rh 21 Oct '19

21 Oct '19

URL: https://github.com/SSSD/sssd/pull/390 Author: mzidek-rh Title: #390: NSS: Add option to disable memcache Action: opened PR body: """ Added option use_memcache to centrally disable memcache for all clients without the need to specify SSS_NSS_USE_MEMCACHE=NO environment variable. Resolves: https://pagure.io/SSSD/sssd/issue/3496 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/390/head:pr390 git checkout pr390

8 106

[sssd PR#546][opened] TESTS: Re-add tests for `kdestroy -A`
by fidencio 23 Sep '19

23 Sep '19

URL: https://github.com/SSSD/sssd/pull/546 Author: fidencio Title: #546: TESTS: Re-add tests for `kdestroy -A` Action: opened PR body: """ This reverts commit 89726be5a05493b7af312f0be9ac5ecb6f1822e1 and also do a few modifications on it in order to ensure we don't have any regression on https://pagure.io/SSSD/sssd/issue/3413 As this patch depends on a krb5 patch applied to the distros we run our internal CI on, I've opened a bug report providing patches for Fedora[0] and Debian[1]. [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1561917 [1]: https://salsa.debian.org/debian/krb5/merge_requests/1 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/546/head:pr546 git checkout pr546

4 27

[sssd PR#560][opened] NSS: close files after mmap
by ChrisKowalczyk 17 Sep '19

17 Sep '19

URL: https://github.com/SSSD/sssd/pull/560 Author: ChrisKowalczyk Title: #560: NSS: close files after mmap Action: opened PR body: """ The files in MC cache folder were initialized by SSSD on startup, and mapped by using mmap function. due to the fact that they weren't closed afterwards, their File descriptors were still marker alive but marked as 'Deleted'. This was noticed by a customer of SUSE, see more details here: https://bugzilla.suse.com/show_bug.cgi?id=1080156 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/560/head:pr560 git checkout pr560

6 12

[sssd PR#541][opened] memberof: keep memberOf attribute for nested member
by pbrezina 08 Apr '19

08 Apr '19

URL: https://github.com/SSSD/sssd/pull/541 Author: pbrezina Title: #541: memberof: keep memberOf attribute for nested member Action: opened PR body: """ If we have a member that is both direct and nested member, memberOf attribute was removed if the direct membership was deleted. 1) user ----------> groupB -> groupC -> groupA / 2) user -> groupA -> groupB -> groupC If we remove user->groupB from 1), we get 2) but groupB was still removed from user memberOf attribute. Resolves: https://pagure.io/SSSD/sssd/issue/3636 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/541/head:pr541 git checkout pr541

3 16

[sssd PR#413][opened] mmap_cache: add SID and type to struct sss_mc_rec
by sumit-bose 16 Oct '18

16 Oct '18

URL: https://github.com/SSSD/sssd/pull/413 Author: sumit-bose Title: #413: mmap_cache: add SID and type to struct sss_mc_rec Action: opened PR body: """ This patchset updates the memory cache by adding some new members to struct sss_mc_rec. One is the addition of a hash value for SID based lookup which will be added in later patches. The other is a new record type and a member indicating the type. The new type is a link record which links an alias name, e.g. an UPN, to the original record of the related user or group object. Besides aliases this link record will be used in case in-sensitive setups. E.g. if getpwnam() returns the name of an AD users as Administrator(a)ad.domain bit some applications or users use administrator(a)ad.domain for lookups the memory cache is currently never used because there is no entry with the hash of 'administrator(a)ad.domain'. With this patch the original data record is created as before with the hash for 'Administrator(a)ad.domain' and a link record is create with the hash of 'administrator(a)ad.domain'. Now both lookups can be handled by the memory cache. If now another application uses ADMINISTRATOR(a)AD.DOMAIN for lookups the first request will go to the NSS responder but upcoming requests can use the memory cache as well because a link record for ADMINISTRATOR(a)AD.DOMAIN is created. The last patch in this series adds some additional data to the user and group lookup requests, the short name, the domain name, the short domain name and the SID. Those are needed to be able to support SID based lookups in the memory cache and allow applications to not depend on the name format returned by getpw{nam|uid}. Upcoming patches for libsss_nss_idmap will make those additional values available to applications I added them already here to keep the memory cache related changes in one PR. Application which will benefit here are the interfaces SSSD provides e.g. to Samba related applications like SSSD's version of libwbclient but also IPA plugins like extdom and slapi-nis. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/413/head:pr413 git checkout pr413

3 5

[sssd PR#397][opened] cleanup: Remove CONFDB_DOMAIN_LEGACY_PASS
by amitkumar50 13 Aug '18

13 Aug '18

URL: https://github.com/SSSD/sssd/pull/397 Author: amitkumar50 Title: #397: cleanup: Remove CONFDB_DOMAIN_LEGACY_PASS Action: opened PR body: """ Since CONFDB_DOMAIN_LEGACY_PASS is legacy parameter that is rooted in pre-1.0 SSSD. We should just nuke it as we remove other legacy code. Resolves: https://pagure.io/SSSD/sssd/issue/3530 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/397/head:pr397 git checkout pr397

5 24

[sssd PR#568][opened] Strip whitespaces in netgroup triple.
by malyzelenyhnus 30 Jul '18

30 Jul '18

URL: https://github.com/SSSD/sssd/pull/568 Author: malyzelenyhnus Title: #568: Strip whitespaces in netgroup triple. Action: opened PR body: """ Strip leading and trailing whitespaces from netgroup three-tuple strings to be compatible with nss_ldap. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/568/head:pr568 git checkout pr568

4 17

[sssd PR#522][opened] Prepare SSSD to support IPA in trust to Samba AD
by abbra 19 Jul '18

19 Jul '18

URL: https://github.com/SSSD/sssd/pull/522 Author: abbra Title: #522: Prepare SSSD to support IPA in trust to Samba AD Action: opened PR body: """ This pull request prepares SSSD ipa provider to support IPA in trust to Samba AD but the same changes are needed for a properly working bi-directional trust against Microsoft AD as well. To make everything fully working, one needs patches against FreeIPA too but SSSD changes are isolated. @sumit-bose @jhrozek please review. 1. When IPA establishes a trust to an Active Directory forest, a number of special objects is created in a subtree of `cn=trusts,$SUFFIX`. These objects represent Kerberos principals for trusted domain objects (TDOs) used for both incoming and outgoing trusts. For bi-directional trust there is a requirement that one of them (`<REMOTE FLAT NAME>$@<OUR REALM>`) must have a POSIX identity because a remote domain controller will use it to authenticate against smbd running on IPA master. SSSD only looks for user accounts in `cn=accounts,$SUFFIX`, so an attempt by smbd to resolve this principal name as a POSIX user via `getpwnam()` will fail. And the reason why smbd behaves this way is due to the fact that a Kerberos ticket used for authentication contains no MS-PAC record, thus not allowing Samba to build a local security token it needs. This is expected for the authentication using TDO account as it is used for bootstrapping reasons (AD DC couldn't create and sign MS-PAC record for an account in IPA realm) but the side effect is that TDO object must be known as a POSIX account on IPA master. Thus, we extend user search base in IPA provider to search in both `cn=accounts,$SUFFIX` and `cn=trusts,$SUFFIX`. Changes on FreeIPA side will handle access controls and generation of the POSIX information for the TDO accounts. 2. For long time we relied on using cross-realm TGTs to talk to Active Directory domain controllers (LDAP and GC services) in case of bi-directional trust. Unfortunately, this is not something we can continue using as there are multiple reasons such access can be denied by a trusted AD side, including SID filtering and other security measurements. It also happens that right now Samba AD in Fedora has a bug in handling a cross-realm TGT generated by the FreeIPA KDC. As result, while technically IPA could establish a bi-directional trust to Samba AD, it does not work as any SSSD attempt to connect to AD DCs via LDAP with GSSAPI will fail (Samba AD DC answers error with PROCESS_TGS message on Kerberos level and authentication fails). For this reason, we should remove any distinction when using bi-directional trust and simply always use a special keytab with a TDO object as we do in uni-directional trust case. While a more generic Kerberos authentication will not work in the outbound direction, SSSD will be able to resolve users/groups. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/522/head:pr522 git checkout pr522

4 17

[sssd PR#586][opened] SSH: Do not exit abruptly if SSHD closes its end of the pipe before reading all the SSH keys
by jhrozek 22 Jun '18

22 Jun '18

URL: https://github.com/SSSD/sssd/pull/586 Author: jhrozek Title: #586: SSH: Do not exit abruptly if SSHD closes its end of the pipe before reading all the SSH keys Action: opened PR body: """ Resolves: https://pagure.io/SSSD/sssd/issue/3747 Before writing the keys to sshd, ignore SIGPIPE so that if the pipe towards the authorizedkeys helper is closed, the sss_ssh_authorizedkeys helper is not terminated with SIGPIPE, but instead proceeds and then the write(2) calls would non-terminally fail with EPIPE. The other patch in this PR is not meant to be pushed. It is an easy way to reproduce the bug. I would also like to write an integration test, but I'm not sure if I can do that very soon and given that we try to release in about a week I prefer to send the fix first. In order to reproduce, load many SSH keys to a user object. I found it was easiest to cheat during reproducing and do this: - first, set a long cache expire so that the cache doesn't expire and overwrite your local changes - ldbedit the cache - copy the ssh public key attribute and each time, change one character in the attribute (ldb would otherwise detect the duplicates) - save the ldbedit window - run the program from the second patch. With the sss_ssh_authorizedkeys patch in, the sss_ssh_authorizedkeys binary should finish gracefully, without the patch, it would fail with SIGPIPE. In my testing, I needed about 30 ssh keys to reproduce the bug. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/586/head:pr586 git checkout pr586

3 14

[sssd PR#579][opened] krb5 locator: add support for multiple addresses and sub-domains
by sumit-bose 14 Jun '18

14 Jun '18

URL: https://github.com/SSSD/sssd/pull/579 Author: sumit-bose Title: #579: krb5 locator: add support for multiple addresses and sub-domains Action: opened PR body: """ Related to https://pagure.io/SSSD/sssd/issue/3652 and https://pagure.io/SSSD/sssd/issue/941. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/579/head:pr579 git checkout pr579

3 22

[sssd PR#585][opened] tcurl: do not log the payload
by fidencio 08 Jun '18

08 Jun '18

URL: https://github.com/SSSD/sssd/pull/585 Author: fidencio Title: #585: tcurl: do not log the payload Action: opened PR body: """ We should never ever log the payload. In order to avoid doing this, let's parse the data and replace the payload content for "...". One example of the log before the patch is: (Wed May 30 21:43:49 2018) [sssd[kcm]] [tcurl_write_data] (0x2000): ---> begin libcurl data (Wed May 30 21:43:49 2018) [sssd[kcm]] [tcurl_write_data] (0x2000): { "version": 1, "kdc_offset": 0, "principal": { "type": 0, "realm": "DOMAIN.TEST", "components": [ "admin" ] }, "creds": [ "uuid": "f87d2975-fc14-4cb8-8275-f0e474f82403", "payload": "AAAAAAAAAAEAAAAPS05PV05IT1NUUy5URVNUAAAABWFkbWluAAAAAAAAAAMAAAAMWC1DQUNIRUNPTkY6AAAAFWtyYjVfY2NhY2hlX2NvbmZfZGF0YQAAAApmYXN0X2F2YWlsAAAAJmtyYnRndC9LTk9XTkhPU1RTLlRFU1RAS05PV05IT1NUUy5URVNUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADeWVzAAAAAA==" } ] } (Wed May 30 21:43:49 2018) [sssd[kcm]] [tcurl_write_data] (0x2000): <--- end libcurl data And after the patch: (Wed May 30 21:45:19 2018) [sssd[kcm]] [tcurl_print_sanitized_data] (0x2000): ---> begin libcurl data (Wed May 30 21:45:19 2018) [sssd[kcm]] [tcurl_print_sanitized_data] (0x2000): { "version": 1, "kdc_offset": 0, "principal": { "type": 0, "realm": "DOMAIN.TEST", "components": [ "admin" ] }, "creds": [ { "uuid": "727b7a15-eba7-4d44-aebe-dc6d1ecaf5f4", "payload": "..." } ] } (Wed May 30 21:45:19 2018) [sssd[kcm]] [tcurl_print_sanitized_data] (0x2000): <--- end libcurl data Resolves: https://pagure.io/SSSD/sssd/issue/3674 Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/585/head:pr585 git checkout pr585

2 12

[sssd PR#582][opened] ipa: MPG realted fixes for lookups by GID
by sumit-bose 08 Jun '18

08 Jun '18

URL: https://github.com/SSSD/sssd/pull/582 Author: sumit-bose Title: #582: ipa: MPG realted fixes for lookups by GID Action: opened PR body: """ There are a few issues when a trusted AD user with an expired cache entry is indirectly looked up be a GID lookup for the primary user private group (mpg). One if the issues was that sysdb_search_group_by_gid() is not aware of MPGs in contrast to sysdb_search_group_by_name(). Since sysdb_search_group_by_gid() is used at other places as well I added sysdb_getgrgid_attrs() to replace sysdb_search_group_by_gid() in get_object_from_cache() instead of modifying to avoid regressions in the other callers. Maybe it would be worth a ticket to check if MPG support can be added safely to sysdb_search_group_by_gid(). Related to https://pagure.io/SSSD/sssd/issue/3748 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/582/head:pr582 git checkout pr582

2 8

[sssd PR#588][opened] nss-imap: add sss_nss_getsidbyuid() and sss_nss_getsidbygid()
by sumit-bose 08 Jun '18

08 Jun '18

URL: https://github.com/SSSD/sssd/pull/588 Author: sumit-bose Title: #588: nss-imap: add sss_nss_getsidbyuid() and sss_nss_getsidbygid() Action: opened PR body: """ Two new calls are added to allow the caller to specify if the given POSIX ID is a UID or a GID and the expected result is a user or a group respectively. This is needed because on POSIX a user and a group may share numerically the same ID value but might have different SIDs assigned. Related to https://pagure.io/SSSD/sssd/issue/3629 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/588/head:pr588 git checkout pr588

2 7

[sssd PR#553][opened] Use p11_child to verify certificates for the ssh responder
by sumit-bose 04 Jun '18

04 Jun '18

URL: https://github.com/SSSD/sssd/pull/553 Author: sumit-bose Title: #553: Use p11_child to verify certificates for the ssh responder Action: opened PR body: """ This patch set is another step to solve https://pagure.io/SSSD/sssd/issue/3489, i.e to remove the NSS dependency and allow all Smartcard and certificate related features to be build with OpenSSL as well. To have all the code related to certificate verification in one place the verification code is removed from the ssh responder and the ssh responder will now call p11_child to verify a certificate before extracting the public key as ssh key. Another benefit is that the ssh responder is not blocked anymore during OCSP check since they now run in p11_child and the ssh responder can process other requests in parallel. In this context I also added a patch which improves the documentation of the feature in the sss_ssh_authorizedkeys man page as requested in https://pagure.io/SSSD/sssd/issue/3688. Besides adding unit tests for the new calls I added an unit test for the ssh responder, similar to the ones for the nss and pam responder. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/553/head:pr553 git checkout pr553

2 10

[sssd PR#587][opened] AUTOFS: remove timed event if related object is removed
by jhrozek 31 May '18

31 May '18

URL: https://github.com/SSSD/sssd/pull/587 Author: jhrozek Title: #587: AUTOFS: remove timed event if related object is removed Action: opened PR body: """ autofs_map_result_timeout() is called as a timed event to free the autofs map data is the cache lifetime is exceeded. If the data is freed earlier the timed event should be removed as well to avoid a double free issue. Since talloc is used here the most easy way to achieve this is to allocate the timed event on the map object itself. Resolves: https://pagure.io/SSSD/sssd/issue/3752 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/587/head:pr587 git checkout pr587

2 10

[sssd PR#580][opened] Revert "CACHE_REQ: Don't force a fqname for files provider' output"
by fidencio 31 May '18

31 May '18

URL: https://github.com/SSSD/sssd/pull/580 Author: fidencio Title: #580: Revert "CACHE_REQ: Don't force a fqname for files provider' output" Action: opened PR body: """ This reverts commit d5c3070c3dd8664b23999f003adc7fd170d19f20. The patch was pushed by mistake and should not be kept nor be part of our tree. Please, mind that we have a similar patch to this one which was reviewed and pushed. That one can be kept. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/580/head:pr580 git checkout pr580

2 6

[sssd PR#577][opened] ipa: Use fqname on selinux_child_setup
by fidencio 31 May '18

31 May '18

URL: https://github.com/SSSD/sssd/pull/577 Author: fidencio Title: #577: ipa: Use fqname on selinux_child_setup Action: opened PR body: """ Although there was a comment saying that pam_selinux needs the username in the same format getpwnam() would return it, it doesn't seem to be the case anymore. Just using fqname from selinux_child_setup allows us to have the expected results. One difference that I've spotted while doing this patch (which may or may not be an issue) is that without this patch the output of `semanage login --list` was always (with or without domain_resolution_order set): [root@client1 x86_64]# semanage login --list Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * admin staff_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * While now I can see: [root@client1 x86_64]# semanage login --list Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * admin staff_u s0-s0:c0.c1023 * admin(a)ipa.example staff_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * Resolves: https://pagure.io/SSSD/sssd/issue/3740 Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> NOTE: While I still have to run downstream tests to be sure it won't introduce regressions (although, it didn't in the very simple test that I've performed) ... I'd appreciate a review (even before the results of the tests) in order to have an early understanding of whether this is a valid approach or not. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/577/head:pr577 git checkout pr577

2 16

[sssd PR#581][opened] LDAP: Do not use signal-unsafe calls in ldap_child SIGTERM handler
by jhrozek 31 May '18

31 May '18

URL: https://github.com/SSSD/sssd/pull/581 Author: jhrozek Title: #581: LDAP: Do not use signal-unsafe calls in ldap_child SIGTERM handler Action: opened PR body: """ The DEBUG macros internally use several signal-unsafe calls so it's better to not use any DEBUG macros at all. man 7 signal-safety lists functions that can be used in a signal handler. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/581/head:pr581 git checkout pr581

2 7

[sssd PR#583][opened] sudo/sysdb regressions
by fidencio 31 May '18

31 May '18

URL: https://github.com/SSSD/sssd/pull/583 Author: fidencio Title: #583: sudo/sysdb regressions Action: opened PR body: """ This patch set consists in 3 patches: - sudo_ldap: fix sudoHost=defaults -> cn=defaults: this is a typo that caused https://pagure.io/SSSD/sssd/issue/3742 - Revert "sysdb custom: completely replace old object instead of merging it": this one caused https://pagure.io/SSSD/sssd/issue/3733 - sysdb_sudo: completely replace old object instead of merging it: As far as I understand, the idea behind cd4590de was to never merged sudo rules. Instead, delete the old one and add the new one. However, doing this all over place caused the regression mentioned above. I've checked the other patches that leaded to this one and seems that keeping the "delete the old one and add the new one" approach may be the cleaner possible way. @pbrezina, may I ask you to (re)test https://pagure.io/SSSD/sssd/issue/3558 in order to be sure that I won't be adding regressions while trying to fix regressions? Also, I do believe this approach is cleaner than adding a new boolean flag in sysdb_store_custom(), do you agree? """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/583/head:pr583 git checkout pr583

2 9

[sssd PR#584][opened] man: Add FILES as a valid config option for 'id_provider'
by tscherf 31 May '18

31 May '18

URL: https://github.com/SSSD/sssd/pull/584 Author: tscherf Title: #584: man: Add FILES as a valid config option for 'id_provider' Action: opened PR body: """ The 'id_provider' config option can now also take 'files' as a valid value. This should be mentioned in man 5 sssd.conf. With this change we are also going to deprecate the 'id_provider = local' setting. Resolves: https://pagure.io/SSSD/sssd/issue/3749 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/584/head:pr584 git checkout pr584

4 11

[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose 31 May '18

31 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support sumit-bose commented: """ ah, sorry, I meant /etc/sssd/pki/sssd_auth_ca_db.pem. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393464732

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose 31 May '18

31 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support sumit-bose commented: """ I changed the path to /etc/sssd/pki/sssd_auth_crl.pem. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393446015

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 30 May '18

30 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ > On 30 May 2018, at 12:39, sumit-bose <notifications(a)github.com> wrote: > > About /etc/sssd/pki, I'm sorry, I didn't understood you correctly in the first place. You suggested to use a directory based CA store (e.g. TLS_CACERTDIR of OpenLDAP) instead of a file based one (e.g. TLS_CACERT of OpenLDAP). If prefer the file bases one because of do not have run some rehash command to create the needed link in the directory store and you can easy link it to other files based stores like e.g. the IPA one. > > Nevertheless we can you /etc/sssd/pki to that the file name will be /etc/sssd/pki/sssd_auth_ca_db.pem. The upcoming file with the CRL will then be /etc/sssd/pki/sssd_auth_crl.pem. And if there is really a need for a directory store we can add e.g. /etc/sssd/pki/ca_certs/. I tried to suggest TLS_CACERT from the start, I just don’t like putting files in the /etc/sssd directory because if we ever want to have e.g. some different access control to a subset of the files, it’s easier to do if the files are in a directory. And if there are multiple related files (like the CRL you mentioned) it’s cleaner to have them in the same directory. > > Do you agree? Yes, I do. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393193240

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose 30 May '18

30 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support sumit-bose commented: """ About /etc/sssd/pki, I'm sorry, I didn't understood you correctly in the first place. You suggested to use a directory based CA store (e.g. TLS_CACERTDIR of OpenLDAP) instead of a file based one (e.g. TLS_CACERT of OpenLDAP). If prefer the file bases one because of do not have run some rehash command to create the needed link in the directory store and you can easy link it to other files based stores like e.g. the IPA one. Nevertheless we can you /etc/sssd/pki to that the file name will be /etc/sssd/pki/sssd_auth_ca_db.pem. The upcoming file with the CRL will then be /etc/sssd/pki/sssd_auth_crl.pem. And if there is really a need for a directory store we can add e.g. /etc/sssd/pki/ca_certs/. Do you agree? """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393114540

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 30 May '18

30 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ > On 30 May 2018, at 11:03, sumit-bose <notifications(a)github.com> wrote: > > Hi Jakub, > > the latest version fixes the softhsm2-util-p11tool issues, if one of the tools is missing the test CA and related tests are not build. Thanks, I’ll test this. > > About additional files, yes there will be e.g. a file with the CRL (certificate revocation list). So you would prefer a subdirectory? I would, but it was just an idea, do you think the flat file is eaiser or better? > Would you like to suggest a name? > /etc/sssd/pki ? > The system CA store contains a lot of public CAs from all over the world and recently there were cases where CAs had to be removed because there were evidence the they issue certificates to people which were not owner of domains or emails mentioned in the certificate. So there is a risk that someone can get a certificate from a CA in the system CA store which would map to your account be rules based mapping. Hence I prefer to have the CA certificates in a file on its own. > > Additionally system CA stores might not be portable to different OS or distributions, so it would be easier for documentation and bug hunting if SSSD has its own file. > OK, thank you for the explanation. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393105818

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose 30 May '18

30 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support sumit-bose commented: """ Hi Jakub, the latest version fixes the softhsm2-util-p11tool issues, if one of the tools is missing the test CA and related tests are not build. About additional files, yes there will be e.g. a file with the CRL (certificate revocation list). So you would prefer a subdirectory? Would you like to suggest a name? The system CA store contains a lot of public CAs from all over the world and recently there were cases where CAs had to be removed because there were evidence the they issue certificates to people which were not owner of domains or emails mentioned in the certificate. So there is a risk that someone can get a certificate from a CA in the system CA store which would map to your account be rules based mapping. Hence I prefer to have the CA certificates in a file on its own. Additionally system CA stores might not be portable to different OS or distributions, so it would be easier for documentation and bug hunting if SSSD has its own file. bye, Sumit """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393086519

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 30 May '18

30 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ Coverity and CI are clean. The last remaining things to discuss before pushing is the default of the CA cert option and maybe skipping the tests. But the code looks good to me and seems to work well. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393077532

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 30 May '18

30 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ > On 28 May 2018, at 13:21, sumit-bose <notifications(a)github.com> wrote: > > Hi @jhrozek, thank you for the review. > > I added 'certmap: allow missing empty EKU in OpenSSL version' to fix the missing EKU issues. The patch also contains a new test certificate without EKU to make sure libcertmap can handle missing EKUs. > > I added default values and man page updates for the CA DB options. I choose /etc/sssd/sssd_auth_ca_db.pem as the default for the OpenSSL build. OK, I verified that this works. The only question that popped into my mind was if it was cleaner to put the cert into a subdirectory of /etc/sssd instead of directly there (c.f. /etc/openldap/certs). But I don’t have strong feelings either way, it would only be a good idea if we anticipate more files than a single one at some point in the future. > I'd prefer not to use system-wide CA bundles like e.g /etc/pki/tls/certs/ca-bundle.crt because if the certificate is mapped to the user not with the full certificate but only based on parts of the certificate content validating the certificate with CA certificates trusted for authentication becomes important. > I’m sorry, but can you explain this in more detail to me? Why would dropping the CA certificate to the system CA cert store be harmful? Or is it to make sure that not another CA cert if picked, but really the one for SSSD? As you say below, we can use tools to make this work for the IPA case, but for the local users with a smart card case, we would need the admin to configure this manually. In RHEL-7, I would have argued that authconfig could help, but in modern Fedoras authselect won’t. > For the IPA case we can discuss with IPA developers if the ipa-advice helper script for Smartcard authentication can create this file as a link to /var/lib/ipa-client/pki/ca-bundle.pem. > Is there a reason not to do this by default as part of ipa-client-install? Since currently the certificate would only be used during cert auth. In general I prefer to have fewer manual steps to configure the client. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393077194

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 30 May '18

30 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ > On 29 May 2018, at 13:50, Jakub Hrozek <notifications(a)github.com> wrote: > > There seems to be one more glitch. If I don't have softsm-util installed, then configure says it can't be found, but then make fails with: > > SOFTHSM2_CONF=./softhsm2_none.conf --init-token --label "SSSD Test Token" --pin 123456 --so-pin 123456 --free > bin/sh: --init-token: command not found OK, I see now that both softshm and gnutls are BuildRequired, so the only reason I didn’t have them installed on my test VM is because I compile from source. It would be nice to fix the tests so that they are skipped if either is not installed, but it’s a minor issue. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. > """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393073321

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 29 May '18

29 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ same issue with p11-tool btw """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-392752386

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 29 May '18

29 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ There seems to be one more glitch. If I don't have `softsm-util` installed, then configure says it can't be found, but then make fails with: ``` SOFTHSM2_CONF=./softhsm2_none.conf --init-token --label "SSSD Test Token" --pin 123456 --so-pin 123456 --free bin/sh: --init-token: command not found ``` """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-392748811

1 0

[sssd PR#570][-Changes requested] p11_child: add OpenSSL support
by jhrozek 29 May '18

29 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support Label: -Changes requested

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose 28 May '18

28 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support sumit-bose commented: """ Hi @jhrozek, thank you for the review. I added 'certmap: allow missing empty EKU in OpenSSL version' to fix the missing EKU issues. The patch also contains a new test certificate without EKU to make sure libcertmap can handle missing EKUs. I added default values and man page updates for the CA DB options. I choose /etc/sssd/sssd_auth_ca_db.pem as the default for the OpenSSL build. I'd prefer not to use system-wide CA bundles like e.g /etc/pki/tls/certs/ca-bundle.crt because if the certificate is mapped to the user not with the full certificate but only based on parts of the certificate content validating the certificate with CA certificates trusted for authentication becomes important. For the IPA case we can discuss with IPA developers if the ipa-advice helper script for Smartcard authentication can create this file as a link to /var/lib/ipa-client/pki/ca-bundle.pem. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-392500377

1 0

[sssd PR#575][opened] DP/LDAP: Only increase the initgrTimestamp when the full initgroups DP request finishes
by jhrozek 28 May '18

28 May '18

URL: https://github.com/SSSD/sssd/pull/575 Author: jhrozek Title: #575: DP/LDAP: Only increase the initgrTimestamp when the full initgroups DP request finishes Action: opened PR body: """ An initgroups request for an AD user consists of two parts - resolving the AD user, which internally calls an LDAP request and adding the IPA external group memberships. For (probably?) historical reasons from the time before we had any notion of subdomains, the initgrTimestamp attribute is written down at the LDAP request level when it finishes -- which means the initgrTimestamp is written before the IPA external group membership is evaluated. When two requests for initgroups arrive semi-concurrently, it can happen that the first request will trigger the whole machinery while the other one would evaluate the initgrTimestamp attribute that was just bumped, but the IPA group memberships were not yet written to the cache. The result is that the second racing request only returns AD groups. This fix removes writing the timestamp from the generic LDAP code and instead writes the timestamp only when the Data Provider request fully returns. Resolves: https://pagure.io/SSSD/sssd/issue/3744 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/575/head:pr575 git checkout pr575

3 6

[sssd PR#574][opened] cache_req: Don't force a fqname for files provider output
by fidencio 28 May '18

28 May '18

URL: https://github.com/SSSD/sssd/pull/574 Author: fidencio Title: #574: cache_req: Don't force a fqname for files provider output Action: opened PR body: """ As we're enforcing the output of files provider to be fully-qualified we can face some weirdness when using domain_resolution_order as: [user@implicit_files@machine]$ This is not only not coherent but also causes issues when the local user, which is managed by the files provider, tries to do a `sudo su`. In this scenario, the user is asked by the password (doesn't matter whether it's part of sudoers) and never is allowed to log-in. In order to avoid the issues described above, let's just not force the output of the files provider to be fully-qualified. NOTE: I do not understand clearly why the issue with sudo happens. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/574/head:pr574 git checkout pr574

3 15

[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose 24 May '18

24 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support sumit-bose commented: """ I think the two issues should be fixed before pushing, I added 'Change requested' """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-391699735

1 0

[sssd PR#570][+Changes requested] p11_child: add OpenSSL support
by sumit-bose 24 May '18

24 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support Label: +Changes requested

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 24 May '18

24 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ oh and the code looks good to me, CI passed and Coverity didn't report any issues. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-391687742

1 0

[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek 24 May '18

24 May '18

URL: https://github.com/SSSD/sssd/pull/570 Title: #570: p11_child: add OpenSSL support jhrozek commented: """ My testing worked well with a Yubikey. I hit two issues: - I couldn't authenticate without EKUs being present in the certificate - I had to manually specify pam_cert_db_path otherwise validation would fail. I'll let Sumit decide if he prefers to have these patched pushed as they are to avoid rebasing or of any of those would be better to fix before pushing. """ See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-391687411

1 0

[sssd PR#576][opened] MAN: Fix the title of the session recording man page
by jhrozek 23 May '18

23 May '18

URL: https://github.com/SSSD/sssd/pull/576 Author: jhrozek Title: #576: MAN: Fix the title of the session recording man page Action: opened PR body: """ s/sudo/session-recording/ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/576/head:pr576 git checkout pr576

2 5

how to run intgcheck?
by Chris Kowalczyk 22 May '18

22 May '18

Hello All, I have been trying to run sssd intgcheck, but to not success. Could you help me with it? Generally, I've been performing the following steps: autoreconf -if ./configure --disable-cifs-idmap-plugin --without-samba \ --without-nfsv4-idmapd-plugin --without-secrets \ --without-kcm --enable-intgcheck-reqs --with-os=suse make intgcheck ...And getting this error: configure: error: source directory already configured; run "make distclean" there first Of course, /make distclean/ destroys all the targets, so this is not a solution. I tried to follow the example in /./contrib/fedora/bashrc_sssd/ and build the tests in a separate directory, but also without success: autoreconf -if cd x86_64 ../configure --disable-cifs-idmap-plugin --without-samba \ --without-nfsv4-idmapd-plugin --without-secrets \ --without-kcm --enable-intgcheck-reqs --with-os=suse make intgcheck Running /make intgcheck/ from /x86_64/ directory complains about missing /cifsidmap/, so clearly there is some problem with configuration. Could you advise me what steps I should take to build and run the integration tests? Regards, Chris

3 3

What's the best way to debug SELinux issues on SSSD?
by Fabiano Fidêncio 22 May '18

22 May '18

People, I've been trying to debug a SELinux issue related to the domain resolution order. Basically, if there's no domain_reoslution_order set: [root@client1 vagrant]# ssh -l admin localhost Password: Last login: Mon May 21 19:00:06 2018 from ::1 [admin@client1 ~]$ id -Z staff_u:staff_r:staff_t:s0-s0:c0.c1023 But, if domain_resolution_order is set: [root@client1 vagrant]# ssh -l admin localhost Password: Last login: Mon May 21 19:30:45 2018 from ::1 [admin@ipa.example@client1 ~]$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 First thing that came to my mind was to take a look at selinux_child.logs, but it didn't give me any clue as the logs are exactly the same for both cases: No domain_resolution_order set: (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main] (0x0400): selinux_child started. (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main] (0x2000): Running with effective IDs: [0][0]. (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main] (0x2000): Running with real IDs [0][0]. (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main] (0x0400): context initialized (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [unpack_buffer] (0x2000): seuser length: 7 (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [unpack_buffer] (0x2000): seuser: staff_u (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [unpack_buffer] (0x2000): mls_range length: 14 (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [unpack_buffer] (0x2000): username length: 5 (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [unpack_buffer] (0x2000): username: admin (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main] (0x0400): performing selinux operations (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser: staff_u mls: s0-s0:c0.c1023 (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [pack_buffer] (0x0400): result [0] (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [prepare_response] (0x4000): r->size: 4 (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351]]]] [main] (0x0400): selinux_child completed successfully domain_resolution_order set: (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main] (0x0400): selinux_child started. (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main] (0x2000): Running with effective IDs: [0][0]. (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main] (0x2000): Running with real IDs [0][0]. (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main] (0x0400): context initialized (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [unpack_buffer] (0x2000): seuser length: 7 (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [unpack_buffer] (0x2000): seuser: staff_u (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [unpack_buffer] (0x2000): mls_range length: 14 (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [unpack_buffer] (0x2000): username length: 5 (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [unpack_buffer] (0x2000): username: admin (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main] (0x0400): performing selinux operations (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser: staff_u mls: s0-s0:c0.c1023 (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [pack_buffer] (0x0400): result [0] (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [prepare_response] (0x4000): r->size: 4 (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398]]]] [main] (0x0400): selinux_child completed successfully Taking a look at the IPA provider, logs also do like the very same: https://paste.fedoraproject.org/paste/FKhvxyj3clzXuE5C7tMGhw (pastebin is huge!) Some tip on which logs I could take a look and/or part of the code I could instrument in order to, at least, get some directions? Thanks in advance, -- Fabiano Fidêncio

2 3

[RFC] sbus2 integration
by Pavel Březina 22 May '18

22 May '18

Hi folks, I sent a mail about new sbus implementation (I'll refer to it as sbus2) [1]. Now, I'm integrating it into SSSD. The work is quite difficult since it touches all parts of SSSD and the changes are usually interconnected but I'm slowly moving towards the goal [2]. At this moment, I'm trying to take "miminum changes" paths so the code can be built and function with sbus2, however to take full advantage of it, it will take further improvements (that will not be very difficult). There is one big change that I would like to take though, that needs to be discussed. It is about how we currently handle sbus connections. In current state, monitor and each backend creates a private sbus server. The current implementation of a private sbus server is not a message bus, it only serves as an address to create point to point nameless connection. Thus each client must maintain several connections: - each responder is connected to monitor and to all backends - each backend is connected to monitor - we have monitor + number of backends private servers - each private server maintains about 10 active connections This has several disadvantages - there are many connections, we cannot broadcast signals, if a process wants to talk to other process it needs to connect to its server and maintain the connection. Since responders do not currently provider a server, they cannot talk between each other. sbus2 implements proper private message bus. So it can work in the same way as session or system bus. It is a server that maintains the connections, keep tracks of their names and then routes messages from one connection to another. My idea is to have only one sbus server managed by monitor. Other processes will connect to this server with a named connection (e.g. sssd.nss, sssd.backend.dom1, sssd.backend.dom2). We can then send message to this message bus (only one connection) and set destination to name (e.g. sssd.nss to invalidate memcache). We can also send signals to this bus and it will broadcast it to all connections that listens to this signals. So, it is proper way how to do it. It will simplify things and allow us to send signals and have better IPC in general. I know we want to eventually get rid of the monitor, the process would stay as an sbus server. It would become a single point of failure, but the process can be restarted automatically by systemd in case of crash. Also here is a bonus question - do any of you remember why we use private server at all? Why don't we connect to system message bus? I do not see any benefit in having a private server. [1] https://github.com/pbrezina/sbus [2] https://github.com/pbrezina/sssd/tree/sbus

6 10

[sssd PR#436][opened] subdomains: Remove code only used in tests
by amitkumar50 21 May '18

21 May '18

URL: https://github.com/SSSD/sssd/pull/436 Author: amitkumar50 Title: #436: subdomains: Remove code only used in tests Action: opened PR body: """ When setting the ad_options in subdomain code there is an condition if (cdb == NULL || conf_path == NULL) True branch is only usable in tests that use old code to initialize the options without confdb context. It would be good to remove dead code. Since cdb, conf_path NULL check is already done inside ad_create_options() Resolves: https://pagure.io/SSSD/sssd/issue/3338 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/436/head:pr436 git checkout pr436

6 15

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel May 2018