sssd-devel April 2017

sssd-devel@lists.fedorahosted.org

12 participants
83 discussions

[sssd PR#165][opened] selinux: Do not fail if SELinux is not managed
by mzidek-rh 06 Apr '17

06 Apr '17

URL: https://github.com/SSSD/sssd/pull/165 Author: mzidek-rh Title: #165: selinux: Do not fail if SELinux is not managed Action: opened PR body: """ Previously we failed if selinux_is_managed returned 0 or -1 (not managed or error). With this patch we only fail in case of error and continue normally if selinux is not managed by libsemanage at all. Resolves: https://fedorahosted.org/sssd/ticket/3297 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/165/head:pr165 git checkout pr165

4 22

Question about ipa_domain option
by Michal Židek 05 Apr '17

05 Apr '17

Hello! When I create a [domain/IPADOMAIN] section and then use the ipa_domain option to use ipadomain.test as a domain name (instead of IPADOMAIN) then SSSD is not able to connect to the ipadomain.test properly. I wonder if someone uses the ipa_domain option and if it makes sense to fix or not. It does not seem to be very useful option to me. But maybe I am using the option wrong. Does anyone know what is the use case for the ipa_domain option (why was it added)? Michal

2 3

[sssd PR#222][opened] ipa_s2n_get_acct_info_send: provide correct req_input name
by pbrezina 03 Apr '17

03 Apr '17

URL: https://github.com/SSSD/sssd/pull/222 Author: pbrezina Title: #222: ipa_s2n_get_acct_info_send: provide correct req_input name Action: opened PR body: """ To avoid crash. Resolves: https://pagure.io/SSSD/sssd/issue/3358 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/222/head:pr222 git checkout pr222

3 9

[sssd PR#224][opened] responders: do not leak selinux context on clients destruction
by pbrezina 03 Apr '17

03 Apr '17

URL: https://github.com/SSSD/sssd/pull/224 Author: pbrezina Title: #224: responders: do not leak selinux context on clients destruction Action: opened PR body: """ The SELinux context created in get_client_cred is not talloc bound and we were leaking it if available with each client's destruction. Resolves: https://pagure.io/SSSD/sssd/issue/3360 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/224/head:pr224 git checkout pr224

2 5

[sssd PR#219][opened] BUILD: Fix compilation of libsss_certmap with libcrypto
by lslebodn 03 Apr '17

03 Apr '17

URL: https://github.com/SSSD/sssd/pull/219 Author: lslebodn Title: #219: BUILD: Fix compilation of libsss_certmap with libcrypto Action: opened PR body: """ CC src/lib/certmap/libsss_certmap_la-sss_cert_content_nss.lo src/lib/certmap/sss_cert_content_nss.c:25:18: fatal error: cert.h: No such file or directory #include <cert.h> ^ compilation terminated. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/219/head:pr219 git checkout pr219

2 6

Design discussion: Support for non-POSIX users and groups
by Jakub Hrozek 03 Apr '17

03 Apr '17

Hi, I prepared a design page for a new feature about fetching and authenticating non-POSIX users: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html For your convenience, I'm also copying the .rst text below: Support for non-POSIX users and groups ====================================== Related ticket(s): ------------------ https://pagure.io/SSSD/sssd/issue/3310 Problem statement ----------------- SSSD, with its D-Bus interface is appealing to applications as a gateway to an LDAP directory where users and groups are stored. However, contrary to the traditional SSSD deployment where all users and groups either have POSIX attributes or those attributes can be inferred from the Windows SIDs, in many cases the users and groups in the application support scenario have no POSIX attributes. At the same time, SSSD especially on the back end (LDAP provider) level currently requires the presence of either an UID number or a Windows SID. This feature tracks adding support for user and group resolution through the D-Bus interface and authn/authz through the PAM interface even for setups without UIDs or Windows SIDs present on the LDAP directory side. Use cases --------- * As an application developer, I want to fetch user attributes for my application from an LDAP server that only uses a fairly generic LDAP objectclasses such as ``groupOfNames`` for groups or ``person`` for users. The application can either issue D-Bus calls itself or rely on Apache modules such as `mod_lookup_identity <https://github.com/adelton/mod_lookup_identity/>`_ * As an application developer, I want to authenticate users to my application using the `mod_authnz_pam <https://github.com/adelton/mod_authnz_pam>`_ module even if the users lack PAM attributes. Overview of the solution ------------------------ On a high level, the most work is tweaking the internal LDAP searches so that they are less restrictive and match users and groups based on just the requested key (typically a name or a UPN) and the configured objectclass. Whether SSSD will restrict the lookups to only POSIX accounts or allow even non-POSIX lookups will be controlled `at the domain level`. This is important for several reasons: * To avoid "leaking" the non-POSIX accounts or, perhaps more importantly, their non-POSIX group memberships to interfaces such as NSS that otherwise require a complete POSIX entry. While these checks could be implemented by the POSIX interfaces as well, making the distinction at the domain level is much safer. * To minimize the number of inconsistencies. These include: * One interface requesting a non-POSIX user through a D-Bus call, then later a POSIX interface searching for the same user. The latter call, having a more restrictive filter, would not match the object in the domain and because we tend to treat the domain reply as authoritative, remove the cached non-POSIX users. * Mixed POSIX and non-POSIX group memberships would require a large amount of special-casing and very careful testing to make sure requests for such hybrid user would return the correct group memberships but at the same time not remove the non-POSIX parts in all cases. * Interfaces that serve both the POSIX and non-POSIX case such as the D-Bus interface need to know whether to return only the list of POSIX group membership if a user that has POSIX attributes is requested. The interfaces cannot assume the intent of the caller and forcing the caller to decide based on the target domain helps here. In short, by forcing to make the distinction on the domain level, the SSSD code would be made more robust and error-prone while limiting the complexity. A non-POSIX domain would be skipped during lookups by interfaces that require POSIX attributes, such as ``sudo`` or ``NSS``. Better distinction must be made for interfaces that support both POSIX and non-POSIX users, though and the details are discussed below. In the simplest case, only a single domain will be defined. The tricky part are setups that must serve data to both the application from a non-POSIX domain and for the OS. For these setups, two ``[domain/]`` sections pointing to the same remote server must be defined, one marked as ``posix`` and one marked as ``application`` type (see below). To distinguish between accounts with the same name that exist in both these domains by interfaces that support both POSIX and non-POSIX domains, a qualified name is the safest way. In addition, the PAM responder will keep a list of application PAM services so that if an unqualified name arrives from an OS-level PAM service (such as ``ssh``), the PAM responder will know it is safe to skip the non-POSIX domains and route the PAM request to POSIX domains only. This would make life easier for accounts that both use the application and OS-level PAM services in the sense that the OS-level PAM interface will be usable even without qualified names. For distinguishing accounts between a POSIX and a non-POSIX domain from the D-Bus inteface, a fully qualified name must be used. But since the D-Bus interface is normally used only by the application, putting the non-POSIX domain first in the ``domains`` list should be enough to avoid using qualified names from the application while still making it possible to use the POSIX domain defined as second in the list. Implementation details and configuration changes ------------------------------------------------ A new SSSD domain option will be added. The option will be called ``domain_type`` and would support two values - ``posix`` and ``application``. The default value will be ``posix``, the non-POSIX support will be enabled by setting the ``domain_type`` to ``application``. When the ``domain_type`` is set to ``application``, SSSD responders that are only usable on a POSIX system (currently ``nss``, ``ssh``, ``sudo``, ``kcm`` and ``secrets``) will skip over ``application`` type domains. This logic will be implemented at the ``cache_req`` level and set by the caller, which is the responder, by adding a ``cache_req`` option. In particular, the ``cache_req`` requests will include an enum with allowed values ``CACHE_REQ_POSIX`` and ``CACHE_REQ_APP`` where the POSIX responders will only use the ``CACHE_REQ_POSIX`` value. The logic that determines which value the ``ifp`` and ``pam`` responders use is described below. The responders that are usable by both applications and the OS as well (that's ``pam`` and ``ifp``) will set a flag for the ``cache_req`` request that will instruct the ``cache_req`` domain-loop to also consider ``application`` domains. The ``ifp`` responder will consider ``application`` domains for all requests. Therefore in order to resolve a POSIX user with only POSIX membership, the request towards the ``ifp`` interface must be qualified with the domain name. The ``pam`` responder will gain a new option ``application_services``. This option will be empty by default. Only PAM services listed in this option will be allowed to contact the ``application`` domains. This option will be added to make sure that unqualified names can still be used in PAM conversations in case both ``posix`` and ``applications`` domains are configured for SSSD. In future, we might add a similar option (with ``UID`` of the caller of the interface as the key) to the ``ifp`` responder as well, but such option will not be added in the first iteration. The last change needed is for Kerberos authentication. Since the Kerberos ticket returned cannot be owned by a POSIX owner in application domains, especially in cases the system would otherwise use a FILE-based ccache, we will use a temporary MEMORY-based ccache in the ``krb5_child`` process destroy the ticket when ``krb5_child`` finishes and only return the resulting error code from the child process to the Data Provider. How To Test ----------- The best way of testing this feature is to test the "full stack" together with an application and the Apache modules. However, isolated testing can be performed as well. All tests expect that the LDAP server is populated with entries that do not contain POSIX attributes or might contain POSIX attributes in the case of mixed setup tests. For testing PAM authn and authz, the ``pam_test_client`` binary built from SSSD sources can be used until ``sssctl`` provides a better way. The users in the test setup should be members of non-POSIX groups, or a mix of POSIX and non-POSIX groups in the mixed scenario setups. #. SSSD with only the ``application`` domain can be reached through the D-Bus and PAM interfaces * Add a domain as follows:: [sssd] domains = appdomain.test services = ifp, pam, nss [pam] application_services = sss_test [ifp] user_attributes = +phone [domain/appdomain.test] id_provider=ldap ldap_uri = ldap://server.test domain_type = application ldap_user_extra_attrs = phone:telephoneNumber * Make sure that a D-Bus call towards the SSSD interface can resolve the ``phone`` attribute of ``$user`` * Test that calling ``pam_test_client auth $user`` succeeds with the correct password. Please note that testing ``auth_provider=krb5`` is also important here to make sure the krb5 provider can deal with ccaches that cannot be owned by a POSIX owner. #. No users or groups from an ``application domain`` can be resolved through the system interfaces * With the setup above, make sure that ``getent passwd $user`` doesn't return the user and even doesn't contact the remote server. * Same test should be performed for the ``ssh``, ``sudo`` and other responders. #. A mixed setup with two domains, one ``posix`` and one ``application`` reports the proper results from all interfaces * Modify the test domain to look like:: [sssd] domains = appdomain.test, posixdomain.test services = ifp, pam, nss [pam] application_services = sss_test [ifp] user_attributes = +phone [domain/appdomain.test] id_provider = ldap ldap_uri = ldap://server.test domain_type = application ldap_user_extra_attrs = phone:telephoneNumber [domain/posixdomain.test] id_provider = ldap ldap_uri = ldap://server.test * Make sure the LDAP server contains a mix of POSIX and non-POSIX users and groups. The POSIX users should be members of a mix of both POSIX and non-POSIX groups. * The tests from the first test case against a non-POSIX user should function as before * However, retrieving the POSIX users should now hit the domain ``posixdomain.test``, so the following should work: * ``getent passwd $posix_user`` should return the POSIX user * ``id $posix_user`` should return only POSIX groups the user is a member of and omit non-POSIX groups * ``getent group $posix_group`` should list all POSIX members of this group. In all the above tests, the NSS responder should skip the ``appdomain.test`` domain completely. * Since the ``appdomain.test`` domain comes first in the domain list, running ``GetUserAttr`` with an unqalified name should return non-POSIX users * Also invoking the ``GetUserGroups`` function should list their non-POSIX groups. Requests qualified to reach the ``posixdomain.test`` domain should only list POSIX groups. #. A mixed setup with two domains, one ``posix`` and one ``application`` can be used for OS-level authentication and authorization * Use the setup from the previous test * Make sure that running a PAM application on the OS level (``su`` or ``ssh`` are good tests) allows the user to log in using shortname as the NSS responder would skip the ``appdomain.test`` completely when the PAM application calls ``initgroups`` and the PAM responder would skip the ``appdomain.test`` domain because the PAM service is not listed in the ``application_services`` option How To Debug ------------ Debug messages listing the domain type must be added to the ``cache_req`` code. Then, the regular method of issuing a request and watching the logs should work. Expiring the cache and using the qualified names is recommeded. Authors ------- * Sumit Bose * Jakub Hrozek * Simo Sorce

3 12

[sssd PR#221][closed] sss_cert_pem_to_der: Accept certificate with data before header
by lslebodn 03 Apr '17

03 Apr '17

URL: https://github.com/SSSD/sssd/pull/221 Author: dkupka Title: #221: sss_cert_pem_to_der: Accept certificate with data before header Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/221/head:pr221 git checkout pr221

1 0

[sssd PR#221][+Pushed] sss_cert_pem_to_der: Accept certificate with data before header
by lslebodn 03 Apr '17

03 Apr '17

URL: https://github.com/SSSD/sssd/pull/221 Title: #221: sss_cert_pem_to_der: Accept certificate with data before header Label: +Pushed

1 0

[sssd PR#221][comment] sss_cert_pem_to_der: Accept certificate with data before header
by lslebodn 03 Apr '17

03 Apr '17

URL: https://github.com/SSSD/sssd/pull/221 Title: #221: sss_cert_pem_to_der: Accept certificate with data before header lslebodn commented: """ master: * 5231ba679402eeb0705a3ecd41f97fdd67d42a69 """ See the full comment at https://github.com/SSSD/sssd/pull/221#issuecomment-291084002

1 0

Remove https://github.com/SSSD/gh-mailinglist-notifications, add https://github.com/SSSD/docs
by Jakub Hrozek 03 Apr '17

03 Apr '17

Hi, I'd like to remove https://github.com/SSSD/gh-mailinglist-notifications -- we're not currently using it, but we're rather using Martin Basti's mail notifier. At the same time, I'd like to add a mirror of https://pagure.io/SSSD/docs to github in order to follow the same process for both docs and code. Right now it's quite confusing to have PRs for code on one place and PRs for docs on another. Anyone against?

4 16

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel April 2017