sssd-devel October 2017

sssd-devel@lists.fedorahosted.org

11 participants
66 discussions

[sssd PR#412][opened] Gpo contributed patches
by mzidek-rh 21 Nov '17

21 Nov '17

URL: https://github.com/SSSD/sssd/pull/412 Author: mzidek-rh Title: #412: Gpo contributed patches Action: opened PR body: """ Hi, I am moving the patches from this PR: https://pagure.io/SSSD/sssd/pull-request/3320 Here on GH. The issue was stalled for a long time, and I do not think it is good idea to ask for changes in the patches after 7 months. So I decided to immediately change all the problems I found and squshed them into the patches in this PR. There were no big issues with the patches: - I rebased it on top of the current master - added missing include for toupper function - the debug message format was not the same as we use on other places (note that this change was difficult to squash for each patch, so not all patches are 'clean', because I squashed all the debug message issues to the GPO: Improve logging of GPO... patch, however the result after applying all patches is as expected) - I added some comments - there were some memory leaks (missing frees) Notice that I am not the author of the patches, only reviewer. The patches as they are in this PR LGTM. I tested them to check if something is broken (manually.. sigh) and now I am waiting for the CI results. There was one issue occuring when I tested these patches and I originally though the is caused by these patches, but now I know it is not. The issue is that I did not have GPOs distributed to all DCs and it looks like SSSD randomly picks one DC and contacts it (even though it was DC from subdomain) so it could not always find all the GPOs (it looked for them on wrong DCs, where they were not). Other then that I encountered no issues with the patches, so it is ACK from me (tentative). However since I am not native speaker and the last patch is MAN page change, I would appreciate second pair of eyes for that patch. Second pair of eyes for the rest of the patches would also be appreciated :) However if nobody raises any issues I will ACK it soon (given the tests will pass). """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/412/head:pr412 git checkout pr412

6 17

[sssd PR#407][opened] Backport of PR#275 to SSSD-1.13
by akamensky 14 Nov '17

14 Nov '17

URL: https://github.com/SSSD/sssd/pull/407 Author: akamensky Title: #407: Backport of PR#275 to SSSD-1.13 Action: opened PR body: """ This patch is a backport of PR #275 for SSSD v1.13 Should only be merged after original PR is accepted. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/407/head:pr407 git checkout pr407

4 8

[sssd PR#408][opened] Backport of PR#275 to SSSD-1.14
by akamensky 14 Nov '17

14 Nov '17

URL: https://github.com/SSSD/sssd/pull/408 Author: akamensky Title: #408: Backport of PR#275 to SSSD-1.14 Action: opened PR body: """ This patch is a backport of PR #275 for SSSD v1.14 Should only be merged after original PR is accepted. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/408/head:pr408 git checkout pr408

5 18

Re: [Freeipa-interest] Announcing SSSD 1.16.0
by Jakub Hrozek 09 Nov '17

09 Nov '17

On Mon, Oct 23, 2017 at 09:19:21PM +0200, Michael Ströder wrote: > Jakub Hrozek wrote: > > On Mon, Oct 23, 2017 at 08:46:08PM +0200, Michael Ströder wrote: > >> Has anything changed with building the man pages? > >> > >> I'm asking because I now get formatting markup in the output of man (see > >> below). > > > > No, not that I'm aware of. You render the man pages locally, right, > > because the tarball only contains the XML sources? > > I'm looking at the man pages generated by the RPM build on openSUSE > build server which IIRC used to work up to sssd release 1.15.2: > > https://build.opensuse.org/package/view_file/home:stroeder:branches:network… > > Ciao, Michael. Nothing changed there for a long time.. If you build the last-known-good (so, 1.15.2) tarball in exactly the same build root, the man pages are rendered fine?

3 7

Design document: Smartcard authentication - Multiple Certificates on a Smartcard
by Sumit Bose 05 Nov '17

05 Nov '17

Hi, please find below the design page for the missing part of https://pagure.io/SSSD/sssd/issue/3050, letting the user select a certificate on the Smartcard at login time. Since the ticket is already closed I opened https://pagure.io/SSSD/sssd/issue/3560 to cover specifically this feature. A nicer formatted version can be found at https://pagure.io/fork/sbose/SSSD/docs/blob/7b97e0bb52223d8440aed27d6126721… bye, Sumit Smartcard authentication - Multiple Certificates on a Smartcard =============================================================== Related ticket(s): ------------------ * https://pagure.io/SSSD/sssd/issue/3050 * https://pagure.io/SSSD/sssd/issue/3560 Problem statement ----------------- Smartcard can contain multiple certificates valid for authentication. Currently SSSD uses only the first valid one returned by the configured PKCS#11 module. SSSD should allow the user to choose the certificate which should be used for authentication at login time. Use cases --------- A Smartcard might contain different certificates which can be used by a single person to authenticate as different roles (different accounts). At login time the user should be able to choose the certificate so that he can login with the expected role. A Smartcard might contain certificates for different purposes which will all match the configured criteria for login (matching and mapping rules) but only one is accepted on the server side for login. At login time the user must be able to select the certificate which is accepted on the server side to login successfully. Overview of the solution ------------------------ The primary way to login to a desktop with a connected Smartcard reader is via GDM. GDM has a special plugin which can detect the insertion of a Smartcard in the reader and start the login process based on this. Recently an extension for a special type of PAM conversation was added (https://bugzilla.gnome.org/show_bug.cgi?id=788851) which allows to easily select from a list of options. SSSD should support the GDM PAM extensions in pam_sss. As a fallback a text based interface which displays a numbered list of options should be used. The user can then enter the number of the certificate which should be used. To make it easy to the user to choose the right certificate the Subject-DNs of the different certificate found on the card should be shown. If would be possible to make this configurable in a later version. Implementation details ---------------------- Currently in the communication between the SSSD components (``pam_sss``, PAM responder, ``p11_child`` and backed) there are already attributes used to uniquely identify a certificate on a Smartcard. This was added with the PKINIT support to make sure the certificate matched by SSSD to the user is the same used by the MIT Kerberos PKINIT plugin. This means that the initial part of the communication between pam_sss and the PAM responders has to be refactored to not only support one set of attributes but multiple. Additionally a user prompt for each certificate (Subject-DN) has to be added to the attributes. As mentioned above ``pam_sss`` should support the GDM PAM extension for an option list besides a simple text based interface. Luckily all internal details of this extension are hidden in macros which are provider by recent version of gdm in the ``/usr/include/gdm/gdm-pam-extensions.h`` header file. This means that there is no additional runtime requirement. On the PAM responder side the code has to be adopted to make sure the user name mapped to the selected certificate is determined before the actual authentication starts, i.e. the authentication request is sent to the backend. Configuration changes --------------------- No configuration changes are needed. If p11_child detects multiple certificate suitable for authentication SSSD should allow the user to select one. How To Test ----------- To test this feature a Smartcard with multiple different certificate (together with the matching private keys) should be created. For different use cases * the certificates can be all mapped to single user * the certificates can be all mapped to different users * only some certificates are mapped while the other are not suitable for authentication * no certificate is mapped to a user How To Debug ------------ All debug data can be found in the usual SSSD log files. For Smartcard authentication ``sssd_pam.log``, ``p11_child.log`` and the backend log file ``sssd_domain.name.log`` are the most important ones. Authors ------- * Sumit Bose <sbose(a)redhat.com>

2 1

Design document: Enhanced NSS API
by Sumit Bose 02 Nov '17

02 Nov '17

Hi, please find below the design document for the enhanced NSS API which makes e.g. the client side timeouts which where recently refactored available to callers. A more visual friendly version can be found at: https://pagure.io/fork/sbose/SSSD/docs/blob/07514ce52845d47fe6bb327f782a865… bye, Sumit Enhanced NSS (Name Service Switch) API ====================================== Related ticket(s): ------------------ https://pagure.io/SSSD/sssd/issue/2478 Problem statement ----------------- The system-wide NSS API provided by glibc with calls like ``getpwnam`` etc might be a bottleneck for applications which are only interested in the data provide by the SSSD backends. It would be possible to load SSSD's NSS plugin ``libnss_sss.so`` with ``dlopen`` and call the provided functions directly. But besides being a bit cumbersome the API defined by NSS is limited and does not offer option to control the behavior of the plugin. Hence a new API provider by SSSD to lookup objects manages by SSSD would be beneficial. Use cases --------- The first users of the new API would be the FreeIPA ``extdom`` and ``slapi-nis`` plugins. Both are use to make information about users and groups from trusted domains available and hence are only interested results from SSSD. Both plugins are run in threads of the 389ds directory server and to work efficiently the current mutex based locking of the connection of SSSD should be improved. Additionally ``slapi-nis`` caches results for performance reasons. Being a part of 389ds it will be notified if 389ds objects like e.g. id-overrides are modified and can drop the cached object. But since SSSD caches results as well a new lookup of the modified object via slapi-nis might still return the old result which will then stay in the cache of ``slapi-nis`` because no now modification is detected. As a result ``slapi-nis`` should be able to invalidate objects in the caches of SSSD to allow a refresh. The ``sss_cache`` is only of limited use here because it requires root privileges and currently invalidates the whole memory cache. Overview of the solution ------------------------ The use cases that the new API should offer a timeout option so that an individual thread does not have to wait until the request is completely handled by SSSD but can abandon from the request and maybe check later if a result is available. Additionally an option to invalidate the cached entires of an individual object are needed. It would be possible to use a set of new calls for this but since most of the processing of such request and similar to the lookup requests it would be more straight forward to use a flag to indicate that the cached entry of the found object should be invalidated. This gives us an API with two new options, a timeout and the bit-field for flags. The flags might be useful for future use cases as well. And the flag to invalidate cached entries of individual objects might be used in future by the ``sss_cache`` utility to make the code simpler and to avoid to completely remove the memory cache. Implementation details ---------------------- Client side ~~~~~~~~~~~ Some of the flags might have influence on the client behavior. E.g. the flag to invalidate the cached entries of an object would tell the client to bypass the memory cache. This is needed because the memory cache will only contain the data of object which were directly requested. But the SSSD on-disk cache might already contain data of objects which are lookup up indirectly, e.g. groups during a initgroups request or users while looking up group members. So a missing entry in the memory cache does not indicate that the entry is missing in the on-disk cache as well. Additionally memory cache and on-disk cache have different timeouts which would require the request to go directly to the SSSD responder as well. For the timeout it has to be kept in mind that in a threaded environment there are two major steps where time might be spend. First is of course the communication with the SSSD responder. But the second is waiting on the mutex. Currently SSSD's NSS plugin ``libnss_sss.so`` uses ``pthread_mutex_lock`` which waits without limits until the mutex can be locked. The reason is that ``libnss_sss.so`` should restrict itself to only use glibc and not libpthread and currently glibc only implements ``pthread_mutex_lock`` (see discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1369130 for details about this requirement). To wait only a limited amount of time libpthread offers ``pthread_mutex_timedlock`` but due to the restriction mentioned above this should be implemented independently of the NSS plugin code. ``libsss_nss_idmap`` looks like the most suitable place for this. New calls ~~~~~~~~~ The API of the new calls will be defined in ``sss_nss_idmap.h``:: /** * Flags to control the behavior and the results for sss_*_ex() calls */ #define SSS_NSS_EX_FLAG_NO_FLAGS 0 /** Always request data from the server side, client must be privileged to do * so, see nss_trusted_users option in man sssd.conf for details. * This flag cannot be used together with SSS_NSS_EX_FLAG_INVALIDATE_CACHE */ #define SSS_NSS_EX_FLAG_NO_CACHE (1 << 0) /** Invalidate the data in the caches, client must be privileged to do * so, see nss_trusted_users option in man sssd.conf for details. * This flag cannot be used together with SSS_NSS_EX_FLAG_NO_CACHE */ #define SSS_NSS_EX_FLAG_INVALIDATE_CACHE (1 << 1) /** * @brief Return user information based on the user name * * @param[in] name same as for getpwnam_r(3) * @param[in] pwd same as for getpwnam_r(3) * @param[in] buffer same as for getpwnam_r(3) * @param[in] buflen same as for getpwnam_r(3) * @param[out] result same as for getpwnam_r(3) * @param[in] flags flags to control the behavior and the results of the * call * @param[in] timeout timeout in milliseconds * * @return * - 0: * - ENOENT: no user with the given name found * - ERANGE: Insufficient buffer space supplied * - ETIME: request timed out but was send to SSSD * - ETIMEDOUT: request timed out but was not send to SSSD */ int sss_nss_getpwnam_timeout(const char *name, struct passwd *pwd, char *buffer, size_t buflen, struct passwd **result, uint32_t flags, unsigned int timeout); /** * @brief Return user information based on the user uid * * @param[in] uid same as for getpwuid_r(3) * @param[in] pwd same as for getpwuid_r(3) * @param[in] buffer same as for getpwuid_r(3) * @param[in] buflen same as for getpwuid_r(3) * @param[out] result same as for getpwuid_r(3) * @param[in] flags flags to control the behavior and the results of the * call * @param[in] timeout timeout in milliseconds * * @return * - 0: * - ENOENT: no user with the given uid found * - ERANGE: Insufficient buffer space supplied * - ETIME: request timed out but was send to SSSD * - ETIMEDOUT: request timed out but was not send to SSSD */ int sss_nss_getpwuid_timeout(uid_t uid, struct passwd *pwd, char *buffer, size_t buflen, struct passwd **result, uint32_t flags, unsigned int timeout); /** * @brief Return group information based on the group name * * @param[in] name same as for getgrnam_r(3) * @param[in] pwd same as for getgrnam_r(3) * @param[in] buffer same as for getgrnam_r(3) * @param[in] buflen same as for getgrnam_r(3) * @param[out] result same as for getgrnam_r(3) * @param[in] flags flags to control the behavior and the results of the * call * @param[in] timeout timeout in milliseconds * * @return * - 0: * - ENOENT: no group with the given name found * - ERANGE: Insufficient buffer space supplied * - ETIME: request timed out but was send to SSSD * - ETIMEDOUT: request timed out but was not send to SSSD */ int sss_nss_getgrnam_timeout(const char *name, struct group *grp, char *buffer, size_t buflen, struct group **result, uint32_t flags, unsigned int timeout); /** * @brief Return group information based on the group gid * * @param[in] gid same as for getgrgid_r(3) * @param[in] pwd same as for getgrgid_r(3) * @param[in] buffer same as for getgrgid_r(3) * @param[in] buflen same as for getgrgid_r(3) * @param[out] result same as for getgrgid_r(3) * @param[in] flags flags to control the behavior and the results of the * call * @param[in] timeout timeout in milliseconds * * @return * - 0: * - ENOENT: no group with the given gid found * - ERANGE: Insufficient buffer space supplied * - ETIME: request timed out but was send to SSSD * - ETIMEDOUT: request timed out but was not send to SSSD */ int sss_nss_getgrgid_timeout(gid_t gid, struct group *grp, char *buffer, size_t buflen, struct group **result, uint32_t flags, unsigned int timeout); /** * @brief Return a list of groups to which a user belongs * * @param[in] name name of the user * @param[in] gid same as second argument of getgrouplist(3) * @param[in] groups array of gid_t of size ngroups, will be filled * with GIDs of groups the user belongs to * @param[in,out] ngroups size of the groups array on input. On output it * will contain the actual number of groups the * user belongs to. With a return value of 0 the * groups array was large enough to hold all group. * With a return valu of ERANGE the array was not * large enough and ngroups will have the needed * size. * @param[in] flags flags to control the behavior and the results of * the call * @param[in] timeout timeout in milliseconds * * @return * - 0: success * - ENOENT: no user with the given name found * - ERANGE: Insufficient buffer space supplied * - ETIME: request timed out but was send to SSSD * - ETIMEDOUT: request timed out but was not send to SSSD */ int sss_nss_getgrouplist_timeout(const char *name, gid_t group, gid_t *groups, int *ngroups, uint32_t flags, unsigned int timeout); SSSD responder side ~~~~~~~~~~~~~~~~~~~ The SSSD NSS responder has to be prepared to accept the flags in the request. Currently only a name or a ID are expected. To handle this new request types: * SSS_NSS_GETPWNAM_EX * SSS_NSS_GETPWUID_EX * SSS_NSS_GETGRNAM_EX * SSS_NSS_GETGRGID_EX * SSS_NSS_INITGR_EX will be added. If the flags are not set will behave as the non-EX calls. If ``SSS_NSS_EX_FLAG_NO_CACHE`` is set ``cache_req_data_set_bypass_cache()`` will be called so that the cache-request framework will directly request new data from the backend. If ``SSS_NSS_EX_FLAG_INVALIDATE_CACHE`` is set ``cache_req_data_set_bypass_dp()`` (which will be implemented with this feature) will be called to only search the requested object in the cache. If it was found the cached entry will be invalidate in both on-disk and memory cache. If ``SSS_NSS_EX_FLAG_INVALIDATE_CACHE`` was sent with SSS_NSS_INITGR_EX both the groupmembership data and the plain user data will be invalidates. The flags ``SSS_NSS_EX_FLAG_NO_CACHE`` and ``SSS_NSS_EX_FLAG_INVALIDATE_CACHE`` cannot be used at the same time. Since both flags might have impact on performace not all caller should be allowed to use them. To configure which user is allowed a new option ``nss_trusted_users`` will be used which will follow the same rules as the already existing option ``pam_trusted_users``. Configuration changes --------------------- A new option ``nss_trusted_users`` will be introduced. A man page entry might look like:: nss_trusted_users (string) Specifies the comma-separated list of UID values or user names that are allowed to run privileged operation in the NSS responder, e.g. bypass the cache and refresh and entry directly. Users not included in this list will get a permissions error. User names are resolved to UIDs at startup. Default: Only UID 0 Please note that UID 0 is always allowed to run privileged operation in the NSS responder even in case it is not in the nss_trusted_users list. How To Test ----------- To test the new calls should be used in C-programs. If flags are used and the calling user will not be root ``nss_trusted_users`` must be set accordingly. How To Debug ------------ ``libsss_nss_idmap`` currently does not has any logging infrastructure so only the debug logs of the SSSD responder are available. If the ``SSS_NSS_EX_FLAG_NO_CACHE`` or ``SSS_NSS_EX_FLAG_INVALIDATE_CACHE`` are used on the client side ``strace`` can be used to see is the client skips the memory cache as expected. Authors ------- * Sumit Bose <sbose(a)redhat.com>

5 10

[sssd PR#427][+Pushed] MAN: GPO Security Filtering limitation
by lslebodn 27 Oct '17

27 Oct '17

URL: https://github.com/SSSD/sssd/pull/427 Title: #427: MAN: GPO Security Filtering limitation Label: +Pushed

1 0

[sssd PR#427][closed] MAN: GPO Security Filtering limitation
by lslebodn 27 Oct '17

27 Oct '17

URL: https://github.com/SSSD/sssd/pull/427 Author: mzidek-rh Title: #427: MAN: GPO Security Filtering limitation Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/427/head:pr427 git checkout pr427

1 0

[sssd PR#427][comment] MAN: GPO Security Filtering limitation
by lslebodn 27 Oct '17

27 Oct '17

URL: https://github.com/SSSD/sssd/pull/427 Title: #427: MAN: GPO Security Filtering limitation lslebodn commented: """ master: * 6c1661d2f4e860d1b547d6188a4fe2bd564e87cf """ See the full comment at https://github.com/SSSD/sssd/pull/427#issuecomment-339986946

1 0

Re: [Freeipa-interest] Announcing SSSD 1.16.0
by Jakub Hrozek 23 Oct '17

23 Oct '17

On Mon, Oct 23, 2017 at 08:46:08PM +0200, Michael Ströder wrote: > HI! > > Has anything changed with building the man pages? > > I'm asking because I now get formatting markup in the output of man (see > below). No, not that I'm aware of. You render the man pages locally, right, because the tarball only contains the XML sources? > > Ciao, Michael. > > SSSD-LDAP(5) > File Formats and Conventions > SSSD-LDAP(5) > > .SH "NAME" sssd-ldap - SSSD LDAP provider > > .SH "DESCRIPTION" > > .PP This manual page describes the configuration of LDAP domains > for sssd(8). Refer to the “FILE FORMAT” section of the sssd.conf(5) > manual page for detailed syntax information. > > .PP You can configure SSSD to use more than one LDAP domain. >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel October 2017