sssd-devel October 2017

sssd-devel@lists.fedorahosted.org

11 participants
66 discussions

[sssd PR#378][opened] [RFC] Use GNULIB's compiler warning code
by fidencio 12 Apr '18

12 Apr '18

URL: https://github.com/SSSD/sssd/pull/378 Author: fidencio Title: #378: [RFC] Use GNULIB's compiler warning code Action: opened PR body: """ This is the 3rd tentative to have this patch reviewed. For more references, please, see: PR #50. So, I've re-worked those patches a little bit and here is the time difference when running reconfing with the patches: ``` real 0m26.047s user 0m21.318s sys 0m4.635s ``` And now without: ``` real 0m25.565s user 0m20.696s sys 0m4.433s ``` This patch set is rebased on top of PR #377. I really would appreciate if someone could review and give their opinion. The reason this PR was blocked is because this time difference has been considered a "performance issue". @jhrozek , could you take a look on this? """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/378/head:pr378 git checkout pr378

4 32

[sssd PR#391][opened] Use dbus-daemon in cwrap enviroment for test
by lslebodn 23 Feb '18

23 Feb '18

URL: https://github.com/SSSD/sssd/pull/391 Author: lslebodn Title: #391: Use dbus-daemon in cwrap enviroment for test Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/391/head:pr391 git checkout pr391

3 25

[sssd PR#394][opened] TESTS: Add an integration test for renaming incomplete groups during initgroups
by jhrozek 19 Feb '18

19 Feb '18

URL: https://github.com/SSSD/sssd/pull/394 Author: jhrozek Title: #394: TESTS: Add an integration test for renaming incomplete groups during initgroups Action: opened PR body: """ This PR depends on https://github.com/SSSD/sssd/pull/128 Adds two regression tests for https://pagure.io/SSSD/sssd/issue/3282 As we implemented the group renaming heuristics to rename only if we can use another "hint" like the original DN or the SID to know the group is the same, this patch adds two tests (positive and negative) to make sure a group with a totally different RDN and hence different originalDN cannot be renamed but a group whose name changed but the RDN stays the same can be renamed. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/394/head:pr394 git checkout pr394

2 7

[sssd PR#237][opened] providers: Move hostid from ipa to sdap
by hvenev 09 Feb '18

09 Feb '18

URL: https://github.com/SSSD/sssd/pull/237 Author: hvenev Title: #237: providers: Move hostid from ipa to sdap Action: opened PR body: """ This just makes sss_ssh_knownhostsproxy work. There is no support for hostgroups (although hostgroups in `ipa` should continue working). I've been using this for a few days with the `ldap` and `krb5` providers and I haven't noticed any regressions. I haven't tested `ipa` and `ad` but all tests seem to pass. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/237/head:pr237 git checkout pr237

6 38

Design page: Automatic private group creation for the LDAP provider
by Jakub Hrozek 16 Jan '18

16 Jan '18

Hi, I wrote a design page about exposing the functionality that creates the user private groups based on the user entry only: https://pagure.io/fork/jhrozek/SSSD/docs/blob/mpg/f/design_pages/auto_priva… For your convenience, I'm also copying the design text in the RST format below. Once the design is approved, I'll propose a PR against the sssd/docs repository. Automatic Private Groups ======================== Related ticket(s): ------------------ https://pagure.io/SSSD/sssd/issue/1872 Problem statement ----------------- This change will enable SSSD to automatically generate private groups for users based on the UID number without the group actually being present as an LDAP object. Use cases --------- The primary use-case is ease of management. The LDAP administrator will only create the user object and add the user to supplementary groups as needed. This has two advantages: * There is one less object to manage and keep in sync with the user * In AD environments, it is not possible to create a user and a group with the same samAccountName, therefore even manually creating the private groups requires the admin to remap the group attribute to a non-default one since by default both users and groups use samAccountName. Overview of the solution ------------------------ Most of the low-level functionality in the sysdb layer had been developed for many years for use in the ``local`` provider. At the same time, there are also most of the infrastrucure ready in the LDAP provider, because the automatic private groups are used by default already for trusted domains. At the moment, the functionality is enabled internally by an option called ``mpg``, short for Magic-Private-Groups. On a high level, the private groups are not created in the SSSD cache at all, but the work is done by the NSS responder which generates the group reply based on the user object only. However, since the ``mpg`` option was always set for truste Therefore, the majority of the work will be exposing the option in configuration and making sure all codepaths work equally well for joined domains as they do for trusted domains. Implementation details ---------------------- A new option needs to be added that would control the user private group creation. In the past, we've had an option called ``magic_private_groups`` and the internal boolean flag inside the ``sss_domain_info`` structure is still called ``mpg``. Instead of resurrecting the old option, we should introduce a newly named option that would be understood by admins better, such as ``auto_private_groups``. The new option must be read on SSSD startup and set the ``sss_domain_info->mpg`` flag, which is currently auto-enabled with sudomains only. The code branch that saves the user (currently ``sdap_save_user``) must be extended to allow setting the GID number to be the same as UID number for any domain that sets the ``mpg`` flag. Care must be taken to store the original GID number (if any) to the ``SYSDB_PRIMARY_GROUP_GIDNUM`` attribute which is then used by the NSS responder to add the original primary GID as a supplementary group. Finally, the group-by-GID LDAP request in the LDAP provider must be extended to make sure that if a private group GID is requested before the user is, the group request will also turn the group-by-GID request to a user-by-UID request which would save the user object which would then allow the NSS responder to auto-generate the group reply. Configuration changes --------------------- A new option ``auto_private_groups`` will be introduced. At the moment, it will only be possible to set the option for the joined domains as the trusted domains always create the private groups already by default. Therefore the only viable usage of this new option in a trusted domain would be `disabling` the functionality, which is out of scope of this RFE. The ``auto_private_groups`` option will default to ``false``. The new option must document that currently the cache must be removed when changing the option value. How To Test ----------- The primary use-cases are SSSD being a client of a generic LDAP server and SSSD on a Linux machine directly joined to an AD domain with ``id_provider=ad``. In both cases, setting the ``auto_private_groups`` option to ``true`` should result in the ``initgroups`` call returning the primary GID number of the user with the same value and resolving to the same name as the primary UID namber and the username. Other intefaces should produce symmetrical results, although at least in the case of the D-Bus based IFP interface, is it currently not the case, see `ticket #3543 <https://pagure.io/SSSD/sssd/issue/3543>`_. For example, here is an output of a test user with private groups autogenerated:: id puser(a)win.trust.test uid=20000(puser(a)win.trust.test) gid=20000(puser(a)win.trust.test) groups=20000(puser@win.trust.test),20002(user1_group2@win.trust.test),20001(user1_group1@win.trust.test),10000(pgroup@win.trust.test) and without:: id puser(a)win.trust.test uid=20000(puser(a)win.trust.test) gid=10000(pgroup(a)win.trust.test) groups=10000(pgroup@win.trust.test),20001(user1_group1@win.trust.test),20002(user1_group2@win.trust.test) Note that in the case of the private groups being generated, the original GID number is turned into a supplementary group by the initgroups call. How To Debug ------------ There's not much extra debugging added for this feature. Debugging this feature should amount to the usual checking of the debug logs. In addition, the cache can be inspected with the ``ldbsearch`` tool to make sure all the groups are saved as expected as well as the ``SYSDB_PRIMARY_GROUP_GIDNUM`` attribute. Authors ------- * Jakub Hrozek <jhrozek(a)redhat.com>

2 3

Design document: A tool to print access control report for IPA clients
by Jakub Hrozek 15 Dec '17

15 Dec '17

Hi, below is a short design page about a new sssctl command that prints the IPA HBAC rules cached on an IPA client. If there are no comments, I'll open a PR against the docs repository. Generate an access control report for IPA domains ================================================= Related ticket(s): ------------------ https://pagure.io/SSSD/sssd/issue/2840 Problem statement ----------------- Some environments require, for auditing reasons, to generate an access control report on the IPA client itself. While it can be argued that generating these reports on the IPA servers instead would provide a nicer experience, the audits requirement sometimes need a tool to be run on the host. Use cases --------- As an owner of an IPA client I need to know which users have access to this client. I want to run a tool on the host and get a report who can access it. The reports must contain information about HBAC rules. In future, SUDO rules would be nice to have as well. Overview of the solution ------------------------ A new ``sssctl`` command called ``access-report``. will be added. This command will only be implemented for IPA domains for now, other domain types will just return an error. The functionality of the command will first trigger PAM access control call to force refresh of the rules and subsequently print all HBAC rule objects from the cache. Configuration changes --------------------- None, only the new tool will be implemented. Implementation details ---------------------- In order to trigger the refresh of rules by ``sssd_be`` process, the tool will call ``pam_acct_mgmt(3)``. The ``user`` and ``service`` that are used in that call will have sensible defaults (e.g. ``admin`` and ``system-auth``) but the tool will also offer command-line switches to override both. In addition, the tool will have a switch to operate purely from cache. For printing the rules, the tool will simply call ``ldb_search``, retrieve all objects of objectclass ``ipaHbacRule`` and then print the RDN value of ``memberUser`` (for users and user groups), ``memberService`` (for services and service groups) and ``category``. By default, groups will not be unrolled, because the ``getgrnam`` interface limits the group nesting by default, therefore it is better to just print the group name, not all the group members. The tool must also print the output in both human-readable and machine-readable formats. For machine readable output, JSON is the best choice, since the KCM responder already depends on ``libjansson.`` How To Test ----------- Run ``sssctl access-report`` on an IPA client with different HBAC rules stored in the cache. Make sure all options produce the desired results. How To Debug ------------ Debug messages will be added to the tool itself. To compare the output with the cache contents, the ``ldbsearch`` tool can be used. The ``ipa`` administration tool can be used to display the server-side HBAC rules. Authors ------- * Jakub Hrozek

2 5

[sssd PR#379][opened] CI: Enable pep8 check
by fidencio 14 Dec '17

14 Dec '17

URL: https://github.com/SSSD/sssd/pull/379 Author: fidencio Title: #379: CI: Enable pep8 check Action: opened PR body: """ As said by the commit log, this PR enables pep8 check in our CI. I really would appreciate to hear @lslebodn's feedback on the patch itself, so I can revisit the commit dropped by @jhrozek that fixes all pep8 warnings and have it added to this series. Anyways, the feedback I'm looking for is basically: Is this patch desired? Is this the right approach? If not, what would you suggest? """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/379/head:pr379 git checkout pr379

4 48

[sssd PR#405][opened] WATCHDOG: Restart providers with SIGUSR2 after time drift
by vtapia 23 Nov '17

23 Nov '17

URL: https://github.com/SSSD/sssd/pull/405 Author: vtapia Title: #405: WATCHDOG: Restart providers with SIGUSR2 after time drift Action: opened PR body: """ Restarting the providers using the already implemented SIGUSR2 (for method .resetOffline, used after netlink detects an interface change) when a time drift is detected, ensures that affected connection retries (e.g. LDAP) will be rescheduled immediately instead of having to wait the time shifted to return to its normal execution. Resolves: https://pagure.io/SSSD/sssd/issue/3285 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/405/head:pr405 git checkout pr405

5 40

[sssd PR#139][opened] Initial revision of sssd pytest framework
by fidencio 21 Nov '17

21 Nov '17

URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: opened PR body: """ sssd-testlib: library containing shared functions to automtate sssd using pytest copr: https://copr.fedorainfracloud.org/coprs/mrniranjan/sssd-testlib/ Signed-off-by: Niranjan M.R <mrniranjan(a)redhat.com> """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139

4 62

[sssd PR#399][opened] Backport of PR#57 to SSSD-1.13
by sumit-bose 21 Nov '17

21 Nov '17

URL: https://github.com/SSSD/sssd/pull/399 Author: sumit-bose Title: #399: Backport of PR#57 to SSSD-1.13 Action: opened PR body: """ Besides cherry-picking the patches some changes were needed to make the patches work on 1.13. To make review easier I didn't squash the changes in but put them in a separate patch. This might cause issues with the CI, so my plan is to squash the changes in after the first round of review. SSSD-1.13 still uses different names in the cache for the configured domain and sub-domains, hence some name related calls had to be adjusted. dp_target_enabled() is not available in 1.13 and I think just checking the schema would be sufficient. In more recent version of SSSD sysdb_group_membership_mod() treats the domain argument only as the domain of the group and the domain of the members are derived from the fully-qualified name. With this patch the domain of the members is determined as well to allow to add members of different domains to a group. This required a small addition to the unit tests as well. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/399/head:pr399 git checkout pr399

3 12

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel October 2017