sssd-devel December 2016

sssd-devel@lists.fedorahosted.org

15 participants
53 discussions

[sssd PR#102][opened] Sssctl no case sensitive searches
by fidencio 06 Jan '17

06 Jan '17

URL: https://github.com/SSSD/sssd/pull/102 Author: mzidek-rh Title: #102: Sssctl no case sensitive searches Action: opened PR body: """ Trying to get rid of branches with smaller patches. Here is one of them. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/102/head:pr102 git checkout pr102

1 21

[sssd PR#89][opened] nss: rewrite nss responder so it uses cache_req
by fidencio 03 Jan '17

03 Jan '17

URL: https://github.com/SSSD/sssd/pull/89 Author: pbrezina Title: #89: nss: rewrite nss responder so it uses cache_req Action: opened PR body: """ Given the size of the current nss responder it was quite impossible to simply switch into using the cache_req interface, especially because most of the code was duplication of cache lookups. This patch completely rewrites the responder from scratch. The amount of code was reduced to less than a half lines of code with no code duplication, better documentation and better maintainability and readability. All functionality should be intact. *Code organization* All protocol (parsing input message and send a reply) is placed in nss_protocol.c. Functions that deals with creating a reply packet are placed into their specific nss_protocol_$object.c files. All supported commands are placed into nss_cmd.c. Functions that deals with cache req are in nss_get_object.c and nss_enum.c. *Code flow for non-enumeration* An nss_getby_$input-type is called for each non-enumeration command. This function parses the input message, creates a cache_req_data structure and issues nss_get_object that calls cache_req. When this request is done nss_getby_done make sure a reply is sent to the client. *Comments on enumeration* I made some effort to make sure enumeration shares the same code for users, groups, services and netgroups. Netgroups now uses nss negative cache instead of implementing its own. *Unit tests* ALl existing unit tests, including the one for nss responder, pass. @mzidek-rh is going to write new unit tests for added functionality into cache_req and sss_ptr_hash interface. Thanks to @spbnick for doing the first round of review, focused on code documentation and readibility. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/89/head:pr89 git checkout pr89

1 62

Design discussion: Fleet Commander integration
by Jakub Hrozek 22 Dec '16

22 Dec '16

Hi, with Alexander's help, I wrote up a design page about how SSSD should read Fleet Commander data from IPA and present them to the FC client component. The SSSD part is described here: https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration and the IPA part is here: https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature… For convenience, I copied the SSSD wiki page below. Comments are welcome! = Feature Name = Related ticket(s): * https://fedorahosted.org/sssd/ticket/2995 === Problem statement === FleetCommander is a service to centrally manage Desktop environments. It includes a server to define desktop profiles and a client to apply profile information to the user's desktop session on a specified machine. This design document describes the SSSD part of an integration of FleetCommander with FreeIPA. The integration is done two-fold, the IPA part of the integration is [https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature… documented separately]. === Use cases === As an administrator, I want to manage desktop profiles in a centralized way As an administrator, I want to use centrally defined users, groups, hosts and host groups to specify how desktop profiles should be applied. As an administrator, I want to make sure desktop profiles associated with a specific user or user group are downloaded and applied on a specific FreeIPA client according to the desktop profile rules defined in FreeIPA. === Overview of the solution === FleetCommander consists on two components: * a web service integrated with Cockpit that serves the dynamic application and the profile data to the network. * and a client side daemon that runs on every host of the network. Since this design page deals with the client side of the whole picture, this paragraph will focus on the integration of the FC client side daemon with SSSD. The FC profiles will be downloaded by a new `session_provider` of IPA. This provider will do nothing by default and will include an option to download FC rules from IPA LDAP (perhaps `ipa_enable_fleetcmd = true`). In order to minimize the required client-side configuration changes, enabling the Fleet Commander client side deamon will drop SSSD configuration that enables the SSSD functionality and restarts SSSD. When a FreeIPA domain user logs in, the IPA provider will download the Fleet Commander profile and rule objects and drop the resulting JSON files into a per-user directory. The file names must be normalized and prepended with priority (please refer to the IPA design page for more details). In the future, we would like to link the Fleet Commander profiles with HBAC rules, but the first implementation will not include this part. === Implementation details === The implementation has two distinct parts -- enabling the IPA session provider's Fleet Commander functionality and actually fetching the Fleet Commander data. ==== Enabling the IPA session provider ==== Since searching for the Fleet Commander profiles does not come for free - at least one LDAP search must be issued, perhaps more unless we cache the host groups, we should only enable this functionality if the Fleet Commander client daemon is enabled as well. To this end, enabling the FC client deamon would trigger a one-shot systemd service that would drop an include file to SSSD's `conf.d` directory. The systemd service might be implemented along these lines: {{{ [Unit] ConditionFileNotEmpty=/etc/sssd/sssd.conf ConditionFileNotEmpty=!/etc/sssd/conf.d/fleetcommander.conf [Service] Type=oneshot ExecStartPre=/bin/cp -y /usr/share/fleetcommander/sssd.snippet.conf /etc/sssd/conf.d/fleetcommander.conf ExecStart=/bin/systemctl try-restart sssd }}} This systemd unit might be stored in `/lib/systemd/system/fleetagent.service.d/sssd.conf`. A similar functionality in this file should remove the included config file when the FC client deamon is disabled. ==== Looking up the Fleet Commander profiles and storing the JSON profile data ==== Since the first implementation will only fetch rules that are linked to this host and the user in question, the SSSD's session provider will issue an LDAP search along these lines: {{{ (&(objectclass=ipadeskprofilerule)(memberHost=my_fqdn_or_my_host_group)(memberUser=user_login_or_group)) }}} All host groups the IPA client is a member of must be included in the `memberHost` part of the filter. Additionally, all user groups must be included in the `memberUser` part of the filter. Since in most cases, the user's groups will be resolved during the login, we will only issue an initgroups request in case the user's initgroups are expired already to cover cases where the sessions provider was invoked separately. The host groups are typically also resolved by the IPA access control provider, but currently not cached. In the initial implementation, we can just search the host groups again, but subsequent patches should optimize the searches by storing the host groups in the cache or in an intermediate in-memory result. The LDAP search will include the Fleet Commander payload data in the profile's `data` attribute. Once the data are known, SSSD will write them to the disk. Since writing to the disk is typically quite fast The JSON files will be stored in a new directory owned by the `sssd-ipa` subpackage. The top-level directory could be at `/var/lib/sss/fleetcmd/` with per-user subdirectories. So each per-user JSON file would be stored at `/var/lib/sss/fleetcmd/<username>/<profilename>.json`. The `<username>` directories need to be owned by the user being logged in. The `<profilename.json>` file must include the priority as a number which is read from the rule's `prio` attribute. The Fleet Commander client deamon will then process the JSON files in this priority. The filenames must also be normalized so that characters with a special meaning in shell are escaped and spaces are converted to another character such as underscores. Please refer to the IPA design page for more details. In the first version, the profiles will always be written again. In the future, we might want to optimize the process further by only writing the JSON profiles if they differ from what's already stored on the disk. This might be doable by storing the modifyTimestamp in the JSON profiles again, if FC is able to ignore certain JSON key-value pairs that would be private to SSSD or just storing the largest USN value of the found profiles in the included directory in a specially-named file. === Configuration changes === Two new configuration options will be added: * `session_provider` that will be inherited from the `id_provider` value, so for IPA clients, this provider will default to `ipa`. A default `session_provider` for other providers will just shortcut and return success. * An option that enables the FC rules and profiles processing. A proposed option name is `ipa_enable_fleetcmd` with boolean semantics. === How To Test === Please see the use-cases above. === How To Debug === DEBUG messages will be added to the new session provider so that the admin can trace if the session provider was invoked at all. An easy way to debug the integration is to enable the sessions provider and the FleetCommander integration manually w/o dropping the file by the FC client side daemon. === Authors === * Alexander Bokovoy * Jakub Hrozek

7 9

[sssd PR#114][opened] sss_ptr_hash_delete_all: use unsigned long int
by fidencio 22 Dec '16

22 Dec '16

URL: https://github.com/SSSD/sssd/pull/114 Author: sumit-bose Title: #114: sss_ptr_hash_delete_all: use unsigned long int Action: opened PR body: """ hash_values() expects a pointer to unsigned long int as second argument. Using size_t instead causes a 'from incompatible pointer type' compiler error on e.g. 32bit platforms because size_t is 32bits here while unsigned long int is 64bits. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/114/head:pr114 git checkout pr114

1 8

releasing 1.15 (alpha?)
by Jakub Hrozek 21 Dec '16

21 Dec '16

Hi, the NSS responder refactoring was merged, the socket activation patches are going to be merged soon, so here's a question: - is it OK to release a tarball when the socket activation patches are merged? Or do we want to merge something else? - should we call the release 1.15 Alpha or something else? I think this answer mostly depends on who would consume this tarball with the two most important changes being internal changes to responder and socket activation. I lean towards calling it 1.15 Alpha Opinions?

1 0

[lslebodn@fedoraproject.org: [sssd-git] master: sss_output_name: do not require fq name (7b293a5)]
by Jakub Hrozek 21 Dec '16

21 Dec '16

Why is it safer to fall back instead of returning an error?

1 0

[sssd PR#111][opened] BUILD: Find a host-prefixed krb5-config when cross-compiling
by fidencio 16 Dec '16

16 Dec '16

URL: https://github.com/SSSD/sssd/pull/111 Author: dm0- Title: #111: BUILD: Find a host-prefixed krb5-config when cross-compiling Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/111/head:pr111 git checkout pr111

1 8

[PATCH] BUILD: Find a host-prefixed krb5-config when cross-compiling
by David Michael 15 Dec '16

15 Dec '16

--- Hi, I've encountered build failures when compiling with a different --host triplet. The krb5-config command would use /usr/bin/krb5-config instead of the host-prefixed version for that target. Using AC_PATH_TOOL in configure.ac addresses this. Can this change be applied? Thanks. David src/external/krb5.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/external/krb5.m4 b/src/external/krb5.m4 index 8fc9096..b844c2f 100644 --- a/src/external/krb5.m4 +++ b/src/external/krb5.m4 @@ -9,7 +9,7 @@ if test x$KRB5_CFLAGS != x; then KRB5_PASSED_CFLAGS=$KRB5_CFLAGS fi -AC_PATH_PROG(KRB5_CONFIG, krb5-config) +AC_PATH_TOOL(KRB5_CONFIG, krb5-config) AC_MSG_CHECKING(for working krb5-config) if test -x "$KRB5_CONFIG"; then KRB5_CFLAGS="`$KRB5_CONFIG --cflags`" -- 2.7.4

2 3

trac cleanup of the 1.14 backlog milestone
by Jakub Hrozek 15 Dec '16

15 Dec '16

Hi, I checked the 1.14 backlog milestone. I think most of the tickets can be just moved to "Future releases" except for a couple where I was quite confident the ticket can be just closed (and I just closed them), except for these: https://fedorahosted.org/sssd/ticket/1400 - [RFE] In memory fast cache should support negative caching https://fedorahosted.org/sssd/ticket/2497 - When machine gets IPA-enrolled to different IPA with the same domain name and the same users, caches prevent correct operation https://fedorahosted.org/sssd/ticket/2967 - Intermittent attribute retrieval failure from AD The three above should IMO be moved to "Patches welcome". Next on my cleanup todo list is 1.14.3 milestone - IMO only bug fixes should be there, the other tickets would just be overlooked since we are not developing new features or new tests for 1.14. Then it's finally time to start drafting the 1.15 milestone..

2 2

[RFC] NSS tlog integration
by Nikolai Kondrashov 09 Dec '16

09 Dec '16

Hi everyone, Please find attached proof-of-concept patches for a part of NSS integration with tlog. Namely, addition of shell substitution for getpwnam requests. The code is supposed to replace a user's shell with /usr/bin/tlog-rec, if session recording is enabled for all users, if it is enabled for that particular user, or for a group that it belongs to. The configuration is done in a dedicated section of sssd.conf named "session_recording", which can contain three options "scope", "users", and "groups". Those correspond to the scope of session recording: "none", "some", and "all", corresponding in order to: disabled session recording, session recording enabled for the specified users/groups, and session recording enabled for all users handled by SSSD. An example of a configuration can be: [session_recording] ; Disabled scope = none or [session_recording] ; Enabled for everyone scope = all or [session_recording] ; Enabled for some users and groups scope = some users = user1, user2 groups = group1, group2 The parts to be done still are adding support for getpwuid and getpwent requests, exporting of the original shell in pam_sss, and of course cleaning it up and doing it according to your comments and requirements. The code has some documentation in doxygen format, which I can change later if we decide on some other format, or no documentation at all. Please, tell me if I'm doing anything wrong this far already, or suggest better ways to do it. Thank you! Nick P.S. I'm on PTO for two weeks starting next week, so might not be able to answer quickly.

3 15

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel December 2016