November 2016 - sssd-devel - Fedora mailing-lists

[sssd PR#50][opened] [RFC] Use GNULIB's compiler warning code
by fidencio 09 Sep '17

09 Sep '17

URL: https://github.com/SSSD/sssd/pull/50 Author: fidencio Title: #50: [RFC] Use GNULIB's compiler warning code Action: opened PR body: """ This patch series was sent to the sssd-devel and some discussions already happened there[0]. I've decided to open the PR because there are some few patches that can be pushed even if we decide to not use the "many warnings" patches. Let's keep track of those patches (and discussions related to them) in the github, in this way we can avoid them to get lost. :-) [0]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.… Best Regards, Changes: 683f72d (Fabiano Fidêncio, 10 weeks ago) BUILD: Make use of GNULIB's compiler warning code As GNULIB has the 'manywarnings' module, which basically turns on every GCC warning, let's make use of it. We can easily blacklist the warnings we cannot cope with, but the main goal should be to have enabled every possible GCC warning. When new GCC warnings are created the 'manywarnings' file can be refreshed from upstream GNULIB. Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> f59828a (Fabiano Fidêncio, 5 days ago) NSS: Fix "old-style-definition" warning caught by GCC Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> f22aff7 (Fabiano Fidêncio, 5 days ago) SIFP: Fix a "jump-misses-init" warning caught by GCC Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> 58609d3 (Fabiano Fidêncio, 5 days ago) RESOLV: Fix a "-Werror=null-dereference" caught by GCC Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> bd1d7fd (Fabiano Fidêncio, 5 days ago) RESOLV: Simplify reply_weight_rearrange() a little bit 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/50/head:pr50 git checkout pr50

1 20

[sssd PR#32][opened] Requesting a pull to SSSD:master from fidencio:wip/#3138
by fidencio 27 Jul '17

27 Jul '17

URL: https://github.com/SSSD/sssd/pull/32 Author: fidencio Title: #32: Requesting a pull to SSSD:master from fidencio:wip/#3138 Action: opened PR body: """ This patch series is intended to solve #3138 by adding a new service that updates the confdb. As part of the series this service is used by secrets service. I only ran CI locally and the two secrets tests have been failing. /o\ Also, I've noticed some weird behavior, where the sssd-update-confdb service starts for apparently no reason, when upgrading fedora packages. Anyways, these pieces of code really need some detailed review as it was the first time I've been "seriously" playing with TEvent requests. So, please, consider it more like an RFC than a well finished and polished code. Best Regards, """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/32/head:pr32 git checkout pr32

3 14

Design document - SSSD KCM server
by Jakub Hrozek 10 Apr '17

10 Apr '17

Hi, I was working on a KCM server for SSSD for some time already in parallel with the files provider and had some discussions with Simo as well. Of course my intent wasn't to implement a feature secretly without a design review, but to have a prototype to base a proper design on :) However it makes sense to have a peer-reviewed design page now, also because of Fedora's move towards Kerberos and KDC proxy, which leads to questions on the Fedora lists about ccache renewals and so on -- so I think it makes sense to pitch the design to Fedora at least already.. Here is the design page: https://fedorahosted.org/sssd/wiki/DesignDocs/KCM and here is the code of the KCM responder so far: https://github.com/jhrozek/sssd/tree/kcm Time-wise, I would like to pivot to return to working on KCM now that the files provider is more or less done and tested. For your convenience, the design page text is included below as well. = KCM server for SSSD = Related ticket(s): * https://fedorahosted.org/sssd/ticket/2887 External links: * [http://k5wiki.kerberos.org/wiki/Projects/KCM_client MIT wiki KCM documentation] === Problem statement === This design page describes adding a new SSSD responder, called `sssd_kcm`. This component would manage Kerberos credential caches and store them in SSSD's secrets storage. === Use cases === * A sysadmin needs to deploy applications in containers without worrying about applications clobbering each other's credential caches in a kernel keyring as keyrings are not namespaced * A user wants to keep having her Kerberos ticket automatically renewed regardless of the ticket being acquired through a PAM conversation with SSSD or from the command line with kinit * A system admin wants to leverage a collection-aware credentials cache for most of applications on their systems, yet enable a legacy application that can only work with a FILE-based ccache to interoperate with them === Overview of the solution === Over time, both libkrb5 and SSSD used different credential cache types to store Kerberos credentials - going from a simple file-based storage (`FILE:`) to a directory (`DIR:`) and most recently a kernel-keyring based cache (`KEYRING:`). Each of these caches has its own set of advantages and disadvantages. The `FILE` ccache is very widely supported, but does not support multiple primary caches. The `DIR` cache does, but creating and managing the directories including proper access control can be tricky. The `KEYRING` cache is not well suited for cases where multiple semi-isolated environments might share the same kernel. Managing credential caches' lifetime is not well solved in neither of these cache types automatically, only with the help of a daemon like SSSD. An interesting credentials cache that might solve the issues mentioned above is `KCM`. With KCM, the Kerberos caches are not stored in a "passive" store, but managed by a daemon. In this setup, the Kerberos library (typically used through an application, like for example, `kinit`) is a "KCM client" and the daemon is being referred to as a "KCM server". Having the Kerberos credential caches managed by a deamon has several advantages: * the daemon is stateful and can perform tasks like Kerberos credential cache renewals or reaping old ccaches. Some tasks, like renewals are possible already with SSSD, but only for tickets that SSSD itself acquired (typically via a login through `pam_sss.so`) and tracks. Tickets acquired otherwise, most notably though kinit wouldn't be tracked and renewed. * since the process runs in userspace, it is subject to UID namespacing, [http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-… unlike the kernel keyring] * unlike the kernel keyring-based cache, which is entirely dependant on UIDs of the caller and in a containerized environment is shared between all containers, the KCM server's entry point is a UNIX socket which can be bind-mounted to only some containers * the protocol between the client and the server can be extended for custom operations such as dumping a cache in a different format to a specific location. This would be beneficial for applications that only understand a certain Kerberos ccache type - for example, some legacy applications only know how to deal with a FILE-based cache, thus preventing the use of cache collections Only the Heimdal Kerberos implementation currently implements a KCM server, but both Heimdal and MIT implement the client-side operations (in libkrb5) to manage KCM-based Kerberos ccaches. This design page describes adding a KCM server to SSSD. While it's of course possible to create a completely standalone deamon that would implement a KCM server, doing so in the context of SSSD has several advantages, notably: * An easy access to the authentication provider of SSSD that already has existing and tested code to renew Kerberos credentials on user's behalf * SSSD already has a D-Bus API that could publish information about Kerberos tickets and for example emit signals that a graphical application can consume * SSSD has a 'secrets provider' to store data at rest. It makes sense to leverage this component to store Kerberos ccaches persistently === Implementation details === A new SSSD responder will be added. Since accessing the Kerberos credentials is quite an infrequent operation, the responder will be socket-activated. This responder would implement the same subset of the KCM protocol the MIT client libraries implement. Contrary to Heimdal's KCM server that just stores the credential caches in memory, the SSSD KCM server would store the ccaches in the secrets database through the sssd-secret's responder [https://jhrozek.fedorapeople.org/sssd/1.14.2/man/sssd-secrets.5.html public REST API]. For user credentials the KCM Server would use a secrets responder URI like `/kcm/users/1234/X` where 1234 is the user ID and X is the residual. The client then gets assigned a KRB5CCNAME of KCM:1234:X. Internally in the secrets responder we will store the credential caches under a new base DN `cn=kcm`. The secret responder's quota on secrets must be made modular to allow different number of secrets per base DN (so, different number of secrets and credentials pretty much). What to do in case the quota is reached is debatable - we should probably first remove service (non-TGT) tickets first for valid TGTs and if that's not possible, just fail. A failure in this case would be no different than a failure if a disk is full when trying to store a FILE-based ccache. The KCM responder would renew the user credentials by starting a tevent timer which would then contact the SSSD Data Provider for the given UID and principal, asking for the credentials to be renewed. Another tevent timer would reap and remove a ccache that reaches its lifetime. In the future, SSSD-specific operations such as writing out a FILE-based ccache might be added. The SSSD D-Bus interface would also be extended to publish information about credentials activity (such as - a ticket being acquired, a ticket was renewed etc) === Configuration changes === No KCM-specific configuration options will be added. The SSSD KCM responder would use the same common options like other SSSD services such as idle timeout. We can add a configurable KCM socket location later, if needed, but for the start it's fine to default to `/var/run/.heim_org.h5l.kcm-socket` mostly because that's what MIT defaults to as well. '''Q''': Should we add an option to explicitly enable ccache renewals and default to no renewals? I don't think this would any any security though, the attacker can just run 'kinit -R' on behalf of the user anyway. === How To Test === In order for the admin to start using the KCM service, the sssd-kcm responder's systemd service must be enabled. Then, libkrb5 must also be configured to use KCM as its default ccache type in `/etc/krb5.conf` {{{ [libdefaults] default_ccache_name = KCM }}} After that, all common operations like kinit, kdestroy or login through pam_sss should just work and store their credentials in the KCM server. The KCM server must implement access control correctly, so even trying to access other user's KCM credentials by setting KRB5CCNAME to `KCM:1234:RESIDUAL` would not work (except for root). Restarting the KCM server or rebooting the machine must persist the tickets. As far as automatic unit and integration testing is required, we need to make sure that MIT's testsuite passes with Kerberos ccache defaulting to KCM and SSSD KCM deamon running. In the SSSD upstream, we should write integration tests that run a MIT KDC under socket_wrapper to exercise the KCM server. === How To Debug === The SSSD KCM server would use the same DEBUG facility as other SSSD services. In order to debug the client side operations, setting the `KRB5_TRACE` variable might come handy. When debugging the setup, the admin might also inspect the SSSD secrets database (if permissable by SELinux policy) to see what credential caches have been stored by the SSSD. === Authors === * Jakub Hrozek <jhrozek(a)redhat.com> * Simo Sorce <simo(a)redhat.com>

3 7

[RFC] Matching and Mapping Certificates
by Sumit Bose 07 Apr '17

07 Apr '17

Hi, I've started to write a SSSD design page about enhancing the current mapping of certificates to users and how to select/match a suitable certificate if multiple certificates are on a Smartcard. My currently thoughts and idea and be found at https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates and for your convenience below as well. Comments and suggestions are welcome. Please let me know about concerns, alternatives and missing use-cases/user-stories. bye, Sumit = Matching and Mapping Certificates = Related ticket(s): * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mappi… === Problem statement === ==== Mapping ==== Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate. ==== Matching ==== Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments. === Use cases === ==== Mapping ==== In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be: * Certificates/Smartcards are issued externally * LDAP schema extension is not possible or not allowed ==== Matching ==== A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login. === Overview of the solution === To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter. === Implementation details === ==== Matching ==== The pkinit plugin of MIT Kerberos must find a suitable certificate from a Smartcard as well and has defined the following syntax (see the pkinit_cert_match section of the krb5.conf man page or http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for details). The main components are * <SUBJECT>regular-expression * <ISSUER>regular-expression * <SAN>regular-expression * <EKU>extended-key-usage-list * <KU>key-usage-list and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator ('&&' is the default). If multiple rules are given they are iterated with the order in the config file as long as a rule matches exactly one certificate. '''Question: MIT Kerberos use case-sensitive matching and POSIX Extended Regular Expression syntax, shall we do the same?''' While <SUBJECT> and <ISSUER> are (imo) already quite flexible I can see some potential extensions for the other components. <EKU> and <KU> in MIT Kerberos only accept certain string values related to some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by what is supported on server side of the pkinit plugin of MIT Kerberos. Since we plan to extend pkinit and support local authentication without pkinit as well I would suggest to allow OID strings for those components as well (the comparison is done on the OID level nonetheless). The <SAN> component in MIT Kerberos only checks the otherName SAN component for the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest to extend this component by allowing to specific an OID with <SAN:O.I.D> ==== Mapping ==== Since different certificates, e.g. issued by different CAs, might have different mapping rule, a matching rule must be added if there are more than 1 mapping rule. A single mapping rule without a matching rule might be used as default/catch-all rule in this case. If multiple rules matches the derived LDAP filter components can be grouped with the or-operator "|". A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ':', e.g. * <SUBJECT:ldapAttributeName> * <SAN:O.I.D.:ldapAttributeName> Currently I see no usage for <ISSUER>, <KU> and <EKU> in mapping rules because they do not contain any user-specific data. If at some point we will have personal CAs we might consider to add <ISSUER> based mappings. '''Question, do we need search-and-replace at all (or at this stage)? Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of <SUBJECT> might be tricky as discussed below. Nevertheless the following might be possible: * <SUBJECT:ldapAttributeName>/regexp/replacement/ * <SAN:O.I.D.:ldapAttributeName>/regexp/replacement/ '''where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like {{{ <SUBJECT:samAccountName>/^CN=$[^,]*$.*$/\1/ }}} '''would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass. '''The search-and-replace does not has to be sed-like because afaik there is not library which offers this and I would like to avoid implementing it. GLib e.g. has [https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expres… g_regex_replace]. Since we already have a GLib dependency in SSSD due to soem utf8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well. ''' ===== Some notes about DNs ===== The X.500 family of standards define names as "SEQUENCE OF RelativeDistinguishedName" where the sequence is "starting with the root and ending with the object being named" (see X.501 section 9.2 for details). On the other hand RFC4514 section 2.1 says "Otherwise, the output consists of the string encoding of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first." This means that the ASN.1 encoded issuer and subject DN from the X.509 certificate can be either displayed as string in the * X.500 order: DC=com,DC=example,CN=users,CN=Certuser or in the * LDAP order: CN=Certuser,CN=Users,DC=example,DC=com As a consequence different tools will use a different order when printing the issuer and subject DN. While NSS's certutil will use the LDAP order, 'openssl x509' and gnutls's certtool will use the X.500 order (the latter might change due to https://gitlab.com/gnutls/gnutls/issues/111). This makes it important to specific the order which is used by SSSD for mapping and matching. I would prefer the LDAP order here. E.g. by default the AD CA uses the DN of the users entry in AD as subject in the issues certificate. So a matching rule like '<SUBJECT:dn>' could tell SSSD to directly search the user based on its DN (which btw is the original intention of the subject field in the certificate, only that the DN should be looked up in a more general DAP as defined by X.500 and not in the lightweight version called LDAP) Another issue is the limited set of attribute names/types required by the RFCs (see section 4.1.2.4 of RFC 3280 and section 3 of RFC 4514). If e.g. the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] is used all tools are able to identify it as an email address but OpenSSL displays it as 'emailAddress=user(a)example.com', certtool as 'EMAIL=user(a)example.com' and certutil as 'E=user(a)example.com'. So matching rules should try to avoid attribute names or only the ones from [https://www.ietf.org/rfc/rfc4514.txt RFC 4514]: * CN commonName (2.5.4.3) * L localityName (2.5.4.7) * ST stateOrProvinceName (2.5.4.8) * O organizationName (2.5.4.10) * OU organizationalUnitName (2.5.4.11) * C countryName (2.5.4.6) * STREET streetAddress (2.5.4.9) * DC domainComponent (0.9.2342.19200300.100.1.25) * UID userId (0.9.2342.19200300.100.1.1) ==== About restricting or enforcing the mapping an matching any further ==== The goal of the matching rules in MIT Kerberos is to select a single certificate from a Smartcard which will then be used for PKINIT. Since we already plan to enhance SSSD to support multiple certificates on a Smartcard and if needed prompt the user which one to use for login we should not enforce that the matching rules should return only a single certificate or nothing. Similar we plan to enhance SSSD to use the same certificate to log in with different user identities, e.g. as a user with standard privileges or as a user with administrator privileges. So it can make sense that multiple mapping rules apply to the same certificate and the related LDAP search filter components are or-ed together. In many cases the login program will first ask for a user name which will help to restrict the number of suitable certificates even further and the mapping rules are only needed to check if the certificate belongs to the user trying to log in. But gdm has a feature where gdm will detect when a Smartcard is inserted and call PAM without a user name. In this case SSSD has to determine the user name based on the certificates found on the Smartcard. If in this case multiple valid certificates are on the card and the mapping rules will return multiple users for each certificate gdm has to display a quite long selection of certificate-user pairs the user has to choose from. So it should be underlined in the documentation that the matching and mapping rules should be detailed and specific so that for the given environment they help to avoid cases where the user is prompted to select a certificate (or user name in the gdm case) when trying to log in. ==== Storing matching and mapping configuration ==== On the IPA server a new objectclass can be created to store an matching-mapping rule pair. Both attributes are optional because a missing mapping rule would mean that the user entry will be search with the whole certificate. A missing matching rule will indicate catch-all rule with a default mapping. Specifying matching-mapping rules in sssd.conf is a bit more complicated because SSSD does not respect multiple entries with the same keyword, only the last one is used. So all rules have to be added to a single line. To give it a little bit of structure the rules can be enclosed by curly-braces '{}{}' and each rule pair is separated by a comma ','. A single rule in curly braces indicates a matching rule and the mapping will be done with the whole certificate. A default/catch-all mapping rule will start with an empty pair of curly braces followed by a pair containing the mapping rule. ===== Examples ===== * '''certificate_rules = {<EKU>msScLogin}''': only allow certificates with have the Microsoft OID for Smartcard logon 1.3.6.1.4.1.311.20.2.2 set. use the whole certificate to look-up the user. The same result can be achieved with * '''certificate_rules = {<EKU>1.3.6.1.4.1.311.20.2.2}''': see above * '''certificate_rules = {<ISSUER>*my-company*<SAN:rfc822Name>*(a)my-company.com$}{<SAN:rfc822Name:mail>}''': only allow certificates form the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use the email address in a LDAP search filter '(mail=email-address)' to find the matching user. === Configuration changes === Does your feature involve changes to configuration, like new options or options changing values? Summarize them here. There's no need to go into too many details, that's what man pages are for. === How To Test === This section should explain to a person with admin-level of SSSD understanding how this change affects run time behaviour of SSSD and how can an SSSD user test this change. If the feature is internal-only, please list what areas of SSSD are affected so that testers know where to focus. === How To Debug === Explain how to debug this feature if something goes wrong. This section might include examples of additional commands the user might run (such as keytab or certificate sanity checks) or explain what message to look for. === Authors === Give credit to authors of the design in this section.

7 23

Tlog integration and packages
by Nikolai Kondrashov 10 Mar '17

10 Mar '17

Hi everyone, I'd like to continue the discussion of tlog integration, and also present you the first release of tlog - a development preview, which has the configuration interface necessary to implement the integration: https://github.com/spbnick/tlog/releases/tag/v1 You're more than welcome to download RPMs, install, read tlog-rec(8) and tlog-rec.conf(5), and experiment! Building from the Git tree and the tarball works as well, if you're so inclined. I'm also attaching those manpages for convenience. Here are the integration plans so far, as discussed with Jakub on our devconf.cz trip meetings and before on the list. Jakub, please correct me or add details. * We follow the route similar to that taken by SELinux rule control implementation [1][2]. I.e. store the configuration in LDAP HBAC rules, write to files on the client side and then specify them to tlog upon user login. However, I'm also rather fond of the idea of specifying the whole configuration through an environment variable instead of through a file referenced by an environment variable - it's not big at all, and we'll avoid the hassle of managing the files. I implemented support for both in tlog (was easy). * We'll have to make nss_sss report user's shell as tlog-rec (how?) and specify the actual shell to tlog-rec via an environment variable, through pam_sss (with SSS_PAM_ENV_ITEM messages). I.e.: * Nss_sss would always report tlog-rec as the user's shell. * During login (e.g. through "login" or "sshd") pam_sss would add a variable to the user environment, containing, or pointing at, a tlog-rec configuration (TLOG_REC_CONF_TEXT or TLOG_REC_CONF_FILE). That configuration would contain the user's actual shell. I can also implement support for a separate variable just for the shell (TLOG_REC_SHELL?) to simplify the implementation for the start. * Tlog-rec would read the system-wide configuration and overlay it with the one specified in the environment, adding the specific user shell, and then would spawn it. Please also see the draft integration design page [3] for reference. I hope to refine and extend it in the coming weeks to match FreeIPA standards. Please chime in and suggest, object, discuss! Also, please report tlog bugs at https://github.com/spbnick/tlog/issues Thank you! Nick [1]: http://www.freeipa.org/page/SELinux_user_mapping [2]: http://www.freeipa.org/images/b/b9/Freeipa30_SELinuxUserMap.pdf [3]: http://www.freeipa.org/page/Session_Recording

5 22

[sssd PR#70][opened] check_duplicate: check name member before using it
by fidencio 22 Feb '17

22 Feb '17

URL: https://github.com/SSSD/sssd/pull/70 Author: sumit-bose Title: #70: check_duplicate: check name member before using it Action: opened PR body: """ The second patch resolves https://fedorahosted.org/sssd/ticket/3231 and adds a test for the issue. The first patches fixes a potential memory leak which so far was only relevant in the tests. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/70/head:pr70 git checkout pr70

3 20

[sssd PR#66][opened] Minor Dynamic DNS fixes
by fidencio 22 Feb '17

22 Feb '17

URL: https://github.com/SSSD/sssd/pull/66 Author: justin-stephenson Title: #66: Minor Dynamic DNS fixes Action: opened PR body: """ To provide a bit more information, one of the fixes is to correct NULL being printed here(https://fedorahosted.org/sssd/ticket/3220): [nsupdate_msg_create_common] (0x0200): Creating update message for realm [(null)]. For the other(https://bugzilla.redhat.com/show_bug.cgi?id=1386748), It is not uncommon for nsupdate to successfully update DNS records but report the error below which results in return(2) to be called inside nsupdate code TSIG error with server: tsig verify failure It is easy to reproduce with AD DNS changing Dynamic DNS to 'Nonsecure and secure' on the Zone Properties. This patch allows PTR records to continue when this happens, however in this case our debug log messages still report failure and I think some improvement should be made here(not sure how exactly though) [child_sig_handler] (0x1000): Waiting for child [3710]. [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [512] [child_sig_handler] (0x0020): child [3710] failed with status [2]. [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158238]: Dynamic DNS update failed It would be nice to correct this at the nsupdate level if this is not the expected behavior also. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/66/head:pr66 git checkout pr66

3 22

[sssd PR#85][opened] SYSDB: Removing of sysdb_try_to_find_expected_dn()
by fidencio 08 Feb '17

08 Feb '17

URL: https://github.com/SSSD/sssd/pull/85 Author: celestian Title: #85: SYSDB: Removing of sysdb_try_to_find_expected_dn() Action: opened PR body: """ Currently in order to match multiple LDAP search results we use two different functions - we have sysdb_try_to_find_expected_dn() but also sdap_object_in_domain(). This patch removes sysdb_try_to_find_expected_dn() and add new sdap_search_initgr_user_in_batch() based on sdap_object_in_domain(). This function covers necessary logic. Resolves: https://fedorahosted.org/sssd/ticket/3230 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/85/head:pr85 git checkout pr85

3 24

[sssd PR#67][opened] UTIL: Unset O_NONBLOCK for ldap connection
by fidencio 25 Jan '17

25 Jan '17

URL: https://github.com/SSSD/sssd/pull/67 Author: lslebodn Title: #67: UTIL: Unset O_NONBLOCK for ldap connection Action: opened PR body: """ Before the commit 75e66c388862a4ba05afe0791c5503226395bad0, the flag O_NONBLOCK was set only for the connect syscall in request sssd_async_connect_send -> sssd_async_connect_send. Such change was done for secrets provider. However, if ldap is compiled with gnutls it caused problems with start_tls and ldaps. OpenLDAP Server log: 5810cf2f connection_get(23): got connid=1042 5810cf2f connection_read(23): checking for input on id=1042 TLS: error: accept - force handshake failure: errno 11 - moznss error -12234 TLS: can't accept: TLS error -12234:SSL received an unexpected Application Data record.. 5810cf2f connection_read(23): TLS accept failure error=-1 id=1042, closing 5810cf2f connection_close: conn=1042 sd=23 sssd domain log: [simple_bind_send] (0x0100): Executing simple bind as: uid=user1,dc=example,dc=com [simple_bind_send] (0x2000): ldap simple bind sent, msgid = 2 [sdap_op_add] (0x2000): New operation 2 timeout 6 [sdap_process_result] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0] [sdap_process_result] (0x2000): Trace: end of ldap_result list [sdap_process_result] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0] [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server] [sdap_handle_release] (0x2000): Trace: sh[0x151c240], connected[1], ops[0x1515700], ldap[0x1511bd0], destructor_lock[0], release_memory[0] [remove_connection_callback] (0x4000): Successfully removed connection callback. [sdap_op_destructor] (0x1000): Abandoning operation 2 [dp_req_done] (0x0400): DP Request [PAM Authenticate #3]: Request handler finished [0]: Success [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #3]: Receiving request data. [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #3]: Request removed. [dp_req_destructor] (0x0400): Number of active DP request: 0 [dp_method_enabled] (0x0400): Target selinux is not configured [dp_pam_reply] (0x1000): DP Request [PAM Authenticate #3]: Sending result [4][LDAP] Resolves: https://fedorahosted.org/sssd/ticket/3189 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/67/head:pr67 git checkout pr67

1 21

[sssd PR#94][opened] Enable {socket,dbus}-activation for responders
by fidencio 23 Jan '17

23 Jan '17

URL: https://github.com/SSSD/sssd/pull/94 Author: fidencio Title: #94: Enable {socket,dbus}-activation for responders Action: opened PR body: """ This series fixes [#2243](https://fedorahosted.org/sssd/ticket/2243), [#3129](https://fedorahosted.org/sssd/ticket/3129) and [#3245](https://fedorahosted.org/sssd/ticket/3245) following what was discussed in the [ML](https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahos… and summed up at [this](https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableRespon… design document. The approach taken was the less intrusive possible and keeps the backward compatibility. [PR#84](https://github.com/SSSD/sssd/pull/84) was closed due to my lack of skills with github. :-\ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/94/head:pr94 git checkout pr94

1 83

[PATCH] Create pidfile after responders have started
by Victor Tapia 09 Jan '17

09 Jan '17

Hi list, The attached patch covers ticket #3080 (https://fedorahosted.org/sssd/ticket/3080). It's based on the following commit: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=d19c4785215305e6eb5f2… Currently, systemd and upstart set the service as 'started' before the responders are available, making service dependencies (with autofs, for instance) unreliable due to a race condition with such dependent services. Creating the pidfile after the responders are up, and monitoring it's creation in the systemd service fixes this race condition. Thanks in advance, Victor

3 23

[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

[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

[PATCH] Unit tests for pam_sss using pam_wrapper (need help with CI..)
by Jakub Hrozek 08 Dec '16

08 Dec '16

Hi, the attached patches implement unit tests for the pam_sss module using pam_wrapper and libpamtest. In my testing, the coverage is around 75% with mostly the parts that require running as root being untested. I worked on this patchset even though the features for 1.14 are in full swing because there are several tickets that will require us to patch pam_sss, so it's important to have the code that changes tested. In addition, when we merge Dan's patches to use TLS with integration tests, then we'll be able to also test authentication in integration tests easily using libpamtest-python. However, our CI fails for me constantly: http://sssd-ci.duckdns.org/logs/job/42/75/fedora_rawhide/ci.html The strange thing is that running CI locally works fine and so does make check. Can anyone help point me in the right direction as to what should I check next? I suspect some of the environment variables might not be set correctly, but I don't see why..

2 8

[sssd PR#95][opened] STAP: Check the number of transactions in the stap aggregate before dereferencing it.
by fidencio 08 Dec '16

08 Dec '16

URL: https://github.com/SSSD/sssd/pull/95 Author: jhrozek Title: #95: STAP: Check the number of transactions in the stap aggregate before dereferencing it. Action: opened PR body: """ None """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/95/head:pr95 git checkout pr95

1 5

[sssd PR#97][opened] IFP: Remove "ChangeDebugTemporarily" method
by fidencio 08 Dec '16

08 Dec '16

URL: https://github.com/SSSD/sssd/pull/97 Author: fidencio Title: #97: IFP: Remove "ChangeDebugTemporarily" method Action: opened PR body: """ This method has been only used by OpenLMI, which has been deprecated and its support dropped from SSSD on commit 99b2352. 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/97/head:pr97 git checkout pr97

1 9

[sssd PR#93][opened] SSH: Use default_domain_suffix for users' authorized keys
by fidencio 06 Dec '16

06 Dec '16

URL: https://github.com/SSSD/sssd/pull/93 Author: jhrozek Title: #93: SSH: Use default_domain_suffix for users' authorized keys Action: opened PR body: """ None """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/93/head:pr93 git checkout pr93

1 11

[sssd PR#27][opened] Minor code changes
by fidencio 02 Dec '16

02 Dec '16

URL: https://github.com/SSSD/sssd/pull/27 Author: mzidek-rh Title: #27: Minor code changes Action: opened PR body: """ Some small changes in the code. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/27/head:pr27 git checkout pr27

1 8

Design document - Socket-activatable responders
by Fabiano Fidêncio 02 Dec '16

02 Dec '16

The design page is done [0] and it's based on this discussion [1] we had on this very same mailing list. A pull-request with the implementation is already opened [2]. [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders [1]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.… [2]: https://github.com/SSSD/sssd/pull/84 The full text of c&p here: = Socket Activatable Responders = Related ticket(s): * https://fedorahosted.org/sssd/ticket/2243 * https://fedorahosted.org/sssd/ticket/3129 === Problem statement === SSSD has some responders which don't have to be running all the time, but could be socket-activated instead in platforms where it's supported. That's the case, for instance, for the IFP, ssh and sudo responders. Making these responders socket-activated would provide a better use experience, as these services could be started on-demand when a client needs them and exist after a period of inactivity. Currently the admin has to explicitly list all the services that might potentially be needed in the `services` section and the processes have to be running all the time. === Use cases === ==== sssctl ==== As more and more features that had been added depending on the IFP responder, we should make sure that the responder is activated on demand and the admins doesn't have to activate it manually. ==== KCM ==== The KCM responder is only seldom needed, when libkrb5 needs to access the credentials store. At the same time, the KCM responder must be running if the Kerberos credentials cache defaults to `KCM`. Socket-activating the responder would solve both of these cases. ==== autofs ==== The autofs responder is typically only needed when a share is about to be mounted. === Overview of the solution === The solution agreed on the mailing list is to add a new unit for each one of the responders. Once a responder is started, it will communicate to the monitor in order to let the monitor know that it's up and the monitor will do the registration of the responder, which basically consists in marking the service as started, increasing the services' counter, getting the responder's configuratiom, adding the responder to the service's list. A configurable idle timeout will be implemented in each responder, as part of this task, in order to exit the responder in case it's not used for a few minutes. === Implementation details === In order to achieve our goal we will need a small modification in responders' common code in order to make it ready for socket-activation, add some systemd units for each of the responders and finally small changes in the monitor code in order to manage the new activated service. The change in the responders' common code is quite trivial, just chnage the sss_process_init code to call activate_unix_sockets() istead of set_unix_socket(). Something like: {{{ - ret = set_unix_socket(rctx, conn_setup); + ret = activate_unix_sockets(rctx, conn_setup); }}} The units that have to be added for each responder must look like: sssd-@responder@.service.in: {{{ [Unit] Description=SSSD @responder@ Service responder Documentation=man:sssd.conf(5) Requires=sssd.service PartOf=sssd.service After=sssd.service [Install] Also=sssd-@responder@.socket [Service] ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files }}} sssd-@responder@.socket.in: {{{ [Unit] Description=SSSD @responder@ Service responder socket Documentation=man:sssd.conf(5) [Socket] ListenStream=@pipepath@/@responder@ [Install] WantedBy=sockets.target }}} Some responders may have more than one socket, which is the case of PAM, so another unit will be needed. sssd-@responder@-priv.socket.in: {{{ [Unit] Description=SSSD @responder@ Service responder private socket Documentation=man:sssd.conf(5) [Socket] ListenStream=@pipepath@/private/@responder@ [Install] WantedBy=sockets.target }}} Last but not least, the IFP responder doesn't have a socket. It's going to be D-Bus activated and some small changes will be required on its D-Bus service unit. {{{ -Exec=@libexecdir@/sssd/sss_signal +Exec=@libexecdir@/sssd/sssd_@responder@ }}} And, finally, the code in the monitor side will have to have some adjustments in order to properly deal with an empty list of services and, also, to register the service when it's started. As just the responders' will be socket-activated for now, the service type will have to exposed and passed through sbus when calling the RegistrationService method and the monitor will have to properly do the registration of the service when RegistrationService's callback is triggered. As mentioned before, the "registration" that has to be done from the monitor's side is: * Mark the service as started; * Increase the services' counter; * Get the responders' configuration; * Set the service's restart number; * Add the service to the services' list. === Configuration changes === After this design is implemented, the "services" line in sssd.conf will become optional for platforms where systemd is present. Note that in order to keep backward compatibility, if the "services" line is present, the services will behave exactly as they did before these changes. === How To Test === The easiest way to test is removing the "services" line from sssd.conf and try to use SSSD normally. Using sssctl tool without having the ifp responder set in the "services" line is another way to test. === How To Debug === The easiest way to debug this new feature is taking a look on the responders' common initialization code and in the monitors' client registration code. Is worth to mention that disabling the systemd's services/sockets will prevent the responders' services to be started. === Authors === Fabiano Fidêncio <fidencio(a)redhat.com> Best Regards, -- Fabiano Fidêncio

8 31

[sssd PR#79][opened] LIBSSS_CONFIG: Drop libsss_config
by fidencio 30 Nov '16

30 Nov '16

URL: https://github.com/SSSD/sssd/pull/79 Author: fidencio Title: #79: LIBSSS_CONFIG: Drop libsss_config Action: opened PR body: """ libssss_config has been used only by OpenLMI and the project has been deprecated making, then, no sense to keep the support on SSSD. Distros that, for some reason, are still packing and distributing OpenLMI can stick to SSSD 1.14 branch. 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/79/head:pr79 git checkout pr79

1 16

[sssd PR#96][opened] CONFDB: Supress clang false passitive warnings
by fidencio 29 Nov '16

29 Nov '16

URL: https://github.com/SSSD/sssd/pull/96 Author: lslebodn Title: #96: CONFDB: Supress clang false passitive warnings Action: opened PR body: """ The errno is macro expandee into '(*__errno_location ())'. The reason is that errno is private in glibc and and the function __errno_location return address of private errno. sh$ objdump -T /lib64/libc.so.6 | grep errno 00000010 g D .tbss 00000004 GLIBC_PRIVATE errno 000208a0 g DF .text 00000011 GLIBC_2.2.5 __errno_location 001366b0 g DF .text 0000005f GLIBC_2.2.5 clnt_sperrno 00136710 g DF .text 00000074 GLIBC_2.2.5 clnt_perrno 00000064 g D .tbss 00000004 GLIBC_PRIVATE __h_errno 0011aad0 g DF .text 00000011 GLIBC_2.2.5 __h_errno_location It looks like clang static analyzer assume that value can be changed due to function call. errno = 0; val = strtol(values[0], NULL, 0); // Taking true branch => assuming "errno != 0" if (errno) { ret = errno; // errno was stored to ret but clang later assumes // that ret can be 0 goto failed; """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/96/head:pr96 git checkout pr96

1 8

[sssd PR#69][opened] krb5: Use command line arguments instead env vars for krb5_child
by fidencio 28 Nov '16

28 Nov '16

URL: https://github.com/SSSD/sssd/pull/69 Author: sumit-bose Title: #69: krb5: Use command line arguments instead env vars for krb5_child Action: opened PR body: """ The first patch resolves https://fedorahosted.org/sssd/ticket/697. The third patch adds some checks for functions I added or extended. As a result I found two memory leaks which are fixed by the second patch. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/69/head:pr69 git checkout pr69

1 24

Design document - SSSD's files provider
by Jakub Hrozek 28 Nov '16

28 Nov '16

Hi, I realized I never sent a design document about the files provider to the sssd-devel list - I'm sorry about that. Nonetheless, I discussed the design with Stephen quite some time ago, so hopefully it's not completely wrong. In general, the plan to "manage the users from files" will have several steps: - sssd will gain id_provider=files. This is done, including tests, there is just a couple of issues to solve -- for example, we need to let the responders know that the entries in the 'files' domain are always up-to-date and the responder should not even be contacted. I pushed the code to: https://github.com/jhrozek/sssd/tree/files - SSSD will always load the files domain, either by letting the distribution drop a configuration snippet and making sure the files provider is always first or just by hardcoding the domain. This is not done and I would like to coordinate with Fabiano's efforts to simplify the sssd config here - the InfoPipe interface will gain writeable interface to either manage the users and groups or set extended attributes Related to this work is Fabiano's effort to make the responders socket-activatable. The full design page can be found at: https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider For your convenience, the full text of the design page is also pasted below: = Feature Name = "Files" data provider Related ticket(s): * The umbrella tracking ticket: https://fedorahosted.org/sssd/ticket/2228 which includes the following sub-tasks: * Ship an immutable recovery mode config for local accounts - https://fedorahosted.org/sssd/ticket/2229 * [RFE] Support UID/GID changes - https://fedorahosted.org/sssd/ticket/2244 * Provide a "writable" D-Bus management API for local users - https://fedorahosted.org/sssd/ticket/3242 === Problem statement === SSSD does not behave well with nscd, so we recommend that it be disabled. However, this comes with a price in the form of every nameservice lookup hitting the disk for {{{/etc/passwd}}} and friends every time. SSSD should be able to read and monitor these files and serve them from its cache, allowing {{{sss}}} to sort before {{{files}}} in {{{/etc/nsswitch.conf}}} In addition, SSSD provides some useful interfaces, such as [https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups the dbus interface] which only work for users and groups SSSD knows about. === Use cases === ==== Use Case: Default Configuration ==== SSSD (and its useful APIs) should always be available. This means that SSSD must ship with a default configuration that works (and requires no manual configuration or joining a domain). This default configuration should provide a fast in-memory cache for all user and group information that SSSD can support, including those traditionally stored in {{{/etc/passwd}}} and friends. ==== Use Case: Programatically managing POSIX attributes of a user or a group ==== Currently the available ways to manage users and groups is either spawn and call shadow-utils binaries like `useradd` or libuser. SSSD already has a D-Bus API used to provide custom attributes of domain users. This interface should be be extended to provide 'writable' methods to manage users and groups from files. This is tracked by [https://fedorahosted.org/sssd/ticket/3242 ticket #3242] ==== Use Case: Manage extended attributes of users and groups ==== Some applications (such as desktop environments) additional attributes (such as keyboard layout) should be stored along with the user. Since the passwd file has only a fixed number of fields, it might make sense to allow additional attributes to be stored in SSSD database and retrieved with sssd's D-Bus interface. Again, this is tracked by [https://fedorahosted.org/sssd/ticket/3242 ticket #3242] === Overview of the solution === SSSD should ship a {{{files}}} provider as part of its required minimal package. Absent any user modifications, SSSD should be configured to start at boot and use this provider to serve local identity information. This provider may or may not be optional. For example, we might decide that it always exists as the first domain in the list, even if not explicitly specified. Alternatively, distributions that wish to always include the files provider will be able (starting with SSSD 1.14 and its [https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge config merging feature]) to drop a definition of the files provider into `/etc/sssd/conf.d`. In order for this functionality to work, we would have to deprecate the `domains` line and instead load all `[domain/XXXX]` sections from all available sources, unless the `domains` line is specified for backwards-compatibility. === Implementation details === Upon SSSD startup, the {{{files}}} provider will always run a complete enumeration pass on the {{{/etc/passwd}}}, {{{/etc/group}}} and other files as appropriate. The provider will then configure an appropriate set of file monitors (using {{{inotify()}}}) and will re-run the enumeration if any of those files are modified or replaced. The implementation of enumeration would use the `nss_files` module interface - we would `dlopen` the module and `dlsym` the appropriate functions like `__nss_files_getpwent`. The fast-cache must also be flushed any time the enumeration is run, to ensure that stale data is cleaned up. We should also consider turning off the fast memory cache while we are performing the update. The {{{files}}} provider in its first incarnation is expected to be a read-only tool, making no direct modifications to local passwords. In future enhancements, the Infopipe may grow the capability to serve the !AccountsServices API and make changes. When a change in the files is detected, we should also flush the negative cache - either only the changes or just flush it whole. This would prevent scenarios like: {{{ getent passwd foo # see that there is no user foo useradd foo # OK, let's add it then getent passwd foo # still no user returned until the negative cache expires }}} from confusing admins. === Configuration changes === We may need the ability to choose non-default locations for files. This can be a hidden (undocumented) option in the first version and if there is a need to actually configure a non-default location, we can later expose these configuration options. We may also need to set a configurable number of seconds between detecting a change and running enumerations. This could be implemented in waiting a short time (2-3 seconds perhaps?) before detecting the change and running the enumeration to avoid excessive enumerations and invalidating the fastacache during subsequent shadow-utils invocations. === Performance impact === For measuring performance impact, we have developed a simple project called [https://github.com/jhrozek/nssbench nssbench] which measures the time spent in NSS with systemtap. For each case, results are included for a single lookup which simulate the simplest case of an application that is spawned and exists and a case where an application performs several lookup and is able to benefit from the memory cache which is opened once per application. For single lookups, we ran the tests 10 times and averaged the Below are test results from different scenarios: 1. Base-line: Looking up a local user directly from `nss_files` * Single lookup {{{ nss operation getpwnam(jhrozek) took 226 us _nss_files_getpwnam cnt:1 avg:30 min:30 max:30 sum:30 us _nss_sss_getpwnam cnt:0 avg:0 min:0 max:0 sum:0 us }}} * 100 lookups {{{ nss operation getpwnam(jhrozek) took 2717 us _nss_files_getpwnam cnt:100 avg:21 min:14 max:524 sum:2159 us _nss_sss_getpwnam cnt:0 avg:0 min:0 max:0 sum:0 us }}} 1. Failover from `sss` to `files` when SSSD is not running - this is the 'worst' case where `sss` is enabled in `nsswitch.conf` but the deamon is not running at all, so the system falls back from `sss` to `files` for user lookups. * Single lookup {{{ nss operation getpwnam(jhrozek) took 549 us _nss_files_getpwnam cnt:1 avg:32 min:32 max:32 sum:32 us _nss_sss_getpwnam cnt:1 avg:72 min:72 max:72 sum:72 us }}} * 100 lookups {{{ nss operation getpwnam(jhrozek) took 6078 us _nss_files_getpwnam cnt:100 avg:19 min:16 max:42 sum:1907 us _nss_sss_getpwnam cnt:100 avg:22 min:19 max:74 sum:2248 us }}} 1. Round-trip between SSSD deamon's populated cache and OS when the memory cache is not used or not populated * Single lookup {{{ nss operation getpwnam(jhrozek) took 755 us _nss_files_getpwnam cnt:0 avg:0 min:0 max:0 sum:0 us _nss_sss_getpwnam cnt:1 avg:384 min:384 max:384 sum:384 us }}} * 100 lookups {{{ nss operation getpwnam(jhrozek) took 97831 us _nss_files_getpwnam cnt:0 avg:0 min:0 max:0 sum:0 us _nss_sss_getpwnam cnt:100 avg:968 min:115 max:22153 sum:96812 us }}} 1. Performance benefit from using the memory cache * Single lookup {{{ nss operation getpwnam(jhrozek) took 373 us _nss_files_getpwnam cnt:0 avg:0 min:0 max:0 sum:0 us _nss_sss_getpwnam cnt:1 avg:37 min:37 max:37 sum:37 us }}} * 100 lookups {{{ nss operation getpwnam(jhrozek) took 1355 us _nss_files_getpwnam cnt:0 avg:0 min:0 max:0 sum:0 us _nss_sss_getpwnam cnt:100 avg:4 min:3 max:42 sum:408 us }}} The testing shows substantial benefit from SSSD cache for applications that perform several lookup. The first lookup, which opens the memory cache file takes about as much time as lookup against files. However, subsequent lookups are almost an order of magnitude faster. For setups that do not run SSSD by default, there is a performance hit by failover from `sss` to `files`. During testing, the failover took up to 300us, about ~70us was spent in the `sss` module and about ~200 us seems to be the failover in libc itself. === Compatibility issues === Unless the ordering is specified, the files provider should be loaded first. Other distributions should be involved as well - we should work with Ubuntu as well. abrt and coredumpd must be run with `SSS_LOOPS=no` in order to avoid looping when analyzing a crash. We need to test this by reverting the order of modules, attaching a debugger and crashing SSSD on purpose. === Packaging issues === We need to add conflicts between glibc an an sssd version that doesn't provide the files provider. === How To Test === When properly configured, SSSD should be able to serve local users and groups. Testing this could be as simple as {{{ getent -s sss passwd localuser }}} Of course, testing on the distribution level could be more involved. For the first phase, of just adding the files provider, nothing should break and the only thing the user should notice is improved performance. Corner cases like running `sssd_nss` under gdb or corefile generation with setup where `sss` is set first in nsswitch.conf must be done as well. === How To Debug === A simple way of checking is some issue is caused by this new setup is to revert the order of NSS modules back to read `files sss`. === Authors === * Stephen Gallagher <sgallagh(a)redhat.com> * Jakub Hrozek <jhrozek(a)redhat.com>

2 1

[sssd PR#4][comment] Added small tweaks to enable SSSD to be compiled with the musl libc
by fidencio 25 Nov '16

25 Nov '16

URL: https://github.com/SSSD/sssd/pull/4 Title: #4: Added small tweaks to enable SSSD to be compiled with the musl libc lslebodn commented: """ @lejonet and BTW I would like to apologise for long gap between reviews """ See the full comment at https://github.com/SSSD/sssd/pull/4#issuecomment-262952035

1 0

[sssd PR#4][comment] Added small tweaks to enable SSSD to be compiled with the musl libc
by fidencio 25 Nov '16

25 Nov '16

URL: https://github.com/SSSD/sssd/pull/4 Title: #4: Added small tweaks to enable SSSD to be compiled with the musl libc lslebodn commented: """ I checked header files on FreeBSD and gid_t is defined in `sys/types.h` as well. Could you check header sys/types.h in musl libc? BTW `ALLPERMS` defined in `sys/stat.h` also on FreeBSD. But current fallback definition in `util.h` cannot cause any problem because `sys/stat.h` is included before your change. It is true that the `MIN` macro in `sys/param.h` but I could not find it anywhere in a documentation/manual pages. We already have fallback definition of the macro in different file `src/util/safe-format-string.c`. I think we can include `sys/param.h` in `src/resolv/async_resolv.c` + `src/util/safe-format-string.c` and remove fallback definition of macro. BTW the `sys/param.h` is included in more files without any `#ifdef-s` ``` src/monitor/monitor.c:#include <sys/param.h> src/providers/ipa/ipa_access.c:#include <sys/param.h> src/providers/ipa/ipa_auth.c:#include <sys/param.h> src/providers/ldap/sdap_access.c:#include <sys/param.h> src/responder/ifp/ifpsrv_util.c:#include <sys/param.h> src/util/crypto/libcrypto/crypto_sha512crypt.c:#include <sys/param.h> src/util/crypto/nss/nss_sha512crypt.c:#include <sys/param.h> ``` """ See the full comment at https://github.com/SSSD/sssd/pull/4#issuecomment-262951847

1 0

[sssd PR#92][opened] UTIL: Fix compilation of sss_utf8 with libunistring
by fidencio 25 Nov '16

25 Nov '16

URL: https://github.com/SSSD/sssd/pull/92 Author: lslebodn Title: #92: UTIL: Fix compilation of sss_utf8 with libunistring Action: opened PR body: """ The internal header file "util/util.h" was removed from sss_utf8.h as part of commit de5fa34860886ad68fba5e739987e16c342e8f14. It was neccessary to ensure libipa_hbac can be build with C90 compatible compiler. This header file includes many system header file and after this change caused missing declaration of the function free() src/util/sss_utf8.c: In function ‘sss_utf8_free’: src/util/sss_utf8.c:40:12: error: implicit declaration of function ‘free’ [-Werror=implicit-function-declaration] return free(ptr); ^~~~ src/util/sss_utf8.c:40:12: warning: incompatible implicit declaration of built-in function ‘free’ src/util/sss_utf8.c:40:12: note: include ‘<stdlib.h>’ or provide a declaration of ‘free’ cc1: some warnings being treated as errors """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/92/head:pr92 git checkout pr92

1 9

[sssd PR#91][opened] sssctl: Fix missing declaration
by fidencio 25 Nov '16

25 Nov '16

URL: https://github.com/SSSD/sssd/pull/91 Author: lslebodn Title: #91: sssctl: Fix missing declaration Action: opened PR body: """ The WEXITSTATUS is defined in stdlib.h on linux. There is a nice comment in stdlib.h: /* Define the macros <sys/wait.h> also would define this way. */ It's better to not rely on this and use more platfom friendly way with including "sys/wait.h". I found this macro mentioned only in the manual page for wait(2) and there is mentioned just the "sys/wait.h" and not "stdlib.h" src/tools/sssctl/sssctl.c: In function 'sssctl_run_command': src/tools/sssctl/sssctl.c:110: error: implicit declaration of function 'WEXITSTATUS' gmake[2]: *** [Makefile:22383: src/tools/sssctl/sssctl-sssctl.o] Error 1 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/91/head:pr91 git checkout pr91

1 9

[sssd PR#88][opened] SYSDB: Remove unused prototype from header file
by fidencio 25 Nov '16

25 Nov '16

URL: https://github.com/SSSD/sssd/pull/88 Author: lslebodn Title: #88: SYSDB: Remove unused prototype from header file Action: opened PR body: """ The function sysdb_get_sudo_filter was removed as part of ticket #2919 I noticed when I was comparing patches between 1.13 and master """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/88/head:pr88 git checkout pr88

1 5

[sssd PR#90][opened] UTIL: Fix implicit declaration of function 'htobe32'
by fidencio 25 Nov '16

25 Nov '16

URL: https://github.com/SSSD/sssd/pull/90 Author: lslebodn Title: #90: UTIL: Fix implicit declaration of function 'htobe32' Action: opened PR body: """ Include internal wrapper header file for endian related functions. CC src/util/cert/nss/libsss_cert_la-cert.lo src/util/cert/nss/cert.c: In function 'cert_to_ssh_key': src/util/cert/nss/cert.c:358: error: implicit declaration of function 'htobe32' gmake[2]: *** [Makefile:12421: src/util/cert/nss/libsss_cert_la-cert.lo] Error 1 gmake[2]: Leaving directory '/root/sssd_from_git' gmake[1]: *** [Makefile:20050: all-recursive] Error 1 gmake[1]: Leaving directory '/root/sssd_from_git' gmake: *** [Makefile:7116: all] Error 2 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/90/head:pr90 git checkout pr90

1 10

[TESTS] test_secrets.py are failing on rawhide
by Lukas Slebodnik 25 Nov '16

25 Nov '16

ehlo, FYI: There are failing integration tests on rawhide test_secrets.py::test_containers FAILED >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> traceback >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Traceback (most recent call last): File "/home/build/sssd/src/tests/intg/test_secrets.py", line 163, in test_containers cli.create_container("mycontainer") File "/home/build/sssd/src/tests/intg/secrets.py", line 136, in create_container res = self.post(name) File "/home/build/sssd/src/tests/intg/secrets.py", line 108, in post return self._request(self.session.post, name, **kwargs) File "/home/build/sssd/src/tests/intg/secrets.py", line 88, in _request self._last_response = cmd(url, **kwargs) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 535, in post return self.request('POST', url, data=data, json=json, **kwargs) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 474, in request prep = self.prepare_request(req) File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 407, in prepare_request hooks=merge_hooks(request.hooks, self.hooks), File "/usr/lib/python2.7/site-packages/requests/models.py", line 302, in prepare self.prepare_url(url, params) File "/usr/lib/python2.7/site-packages/requests/models.py", line 372, in prepare_url raise InvalidURL('URL has an invalid label.') InvalidURL: URL has an invalid label. It is caused by recently upgraded pacakges python2-requests and python2-urllib3 ========================================================================== Package Arch Version Repository ========================================================================== Upgrading: python2-requests noarch 2.12.1-1.fc26 rawhide python2-urllib3 noarch 1.19.1-1.fc26 rawhide Installing dependencies: python-backports x86_64 1.0-8.fc25 rawhide python-backports-ssl_match_hostname noarch 3.5.0.1-3.fc25 rawhide python-enum34 noarch 1.0.4-6.fc25 rawhide python-idna noarch 2.1-1.fc26 rawhide python-ipaddress noarch 1.0.16-3.fc25 rawhide python-pycparser noarch 2.14-7.fc25 rawhide python2-cffi x86_64 1.8.3-2.fc26 rawhide python2-cryptography x86_64 1.5.3-3.fc26 rawhide python2-ply noarch 3.9-1.fc26 rawhide python2-pyOpenSSL noarch 16.2.0-1.fc26 rawhide LS

2 3

trac cleanup of the future releases milestone
by Jakub Hrozek 25 Nov '16

25 Nov '16

Hi, I closed quite a few invalid tickets in the patches welcome milestone today. I also walked through the 'future releases' milestone and created two new reports, one for tickets I would like to move to 'patches welcome': https://fedorahosted.org/sssd/report/36 and one for tickets which I would like to close completely: https://fedorahosted.org/sssd/report/35 if you disagree, please ping me, reply here or in the tickets. If there is no opposition, I will move the tickets next week. Then next week, I would like to process the 1.14 backlog and 1.14.3 milestonies so that we can finally start planning 1.15 a bit nicely without the noise that was in trac..

1 0

[sssd PR#84][opened] Socket-activation of SSSD responders
by fidencio 24 Nov '16

24 Nov '16

URL: https://github.com/SSSD/sssd/pull/84 Author: fidencio Title: #84: Socket-activation of SSSD responders Action: opened PR body: """ This series fixes [#2243](https://fedorahosted.org/sssd/ticket/2243) and [#3129](https://fedorahosted.org/sssd/ticket/3129), following what was discussed in the [ML](https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahos… and summed up at [this](https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableRespon… design document. The approach taken was the less intrusive possible and keeps the backward compatibility. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/84/head:pr84 git checkout pr84

1 3

[sssd PR#87][opened] SYSDB: Only process aliases if they are non-NULL
by fidencio 24 Nov '16

24 Nov '16

URL: https://github.com/SSSD/sssd/pull/87 Author: jhrozek Title: #87: SYSDB: Only process aliases if they are non-NULL Action: opened PR body: """ This bug was found by downstream coverity check. The aliases array is created by sysdb_get_sudo_user_info() which returns a NULL array if there are no aliases. We need to avoid dereferencing the array in that case. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/87/head:pr87 git checkout pr87

1 7

[sssd PR#46][opened] sss_client: Defer thread cancellation until completion of nss/pam operations
by fidencio 24 Nov '16

24 Nov '16

URL: https://github.com/SSSD/sssd/pull/46 Author: HouzuoGuo Title: #46: sss_client: Defer thread cancellation until completion of nss/pam operations Action: opened PR body: """ https://fedorahosted.org/sssd/ticket/3156 The client code is not cancellation-safe, an application which has cancelled an NSS operation will experience subtle bugs, hence thread cancellation is deferred until completion of client operations. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/46/head:pr46 git checkout pr46

1 24

[sssd PR#86][opened] SYSDB: check aliases before using them (sssd-1-13 only)
by fidencio 24 Nov '16

24 Nov '16

URL: https://github.com/SSSD/sssd/pull/86 Author: jhrozek Title: #86: SYSDB: check aliases before using them (sssd-1-13 only) Action: opened PR body: """ If there are no aliases, the array would be NULL and we would crash. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/86/head:pr86 git checkout pr86

1 2

[sssd PR#39][opened] RESPONDER: Enable sudoRule in case insen. domains
by fidencio 24 Nov '16

24 Nov '16

URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains Action: opened PR body: """ This ptach is valid only for SSSD-1-13. It adds value 'ALL' to sudoRule attribute "sudoUser". So if we have case insensitive domain such sudo rule will be work for right users. Resolves: https://fedorahosted.org/sssd/ticket/3203 ---- This is simple patch for solving the ticket. Another solution is backport pbrezina patches what I didn't try yet. If you prefer backport please tell me. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39

1 67

[sssd PR#75][opened] Add configuirable max payload size limit of a secret
by fidencio 24 Nov '16

24 Nov '16

URL: https://github.com/SSSD/sssd/pull/75 Author: fidencio Title: #75: Add configuirable max payload size limit of a secret Action: opened PR body: """ This series may conflict with PR53[0]. So either one or another will need to be rebased after the first one gets merged. [0]: https://github.com/SSSD/sssd/pull/53 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/75/head:pr75 git checkout pr75

1 17

trac cleanup of the patches welcome milestone
by Jakub Hrozek 23 Nov '16

23 Nov '16

Hi, as we're planning what exactly are we going to work on in the next release and also preparing to move away from fedorahosted, I think it makes sense to clean up our Trac. The intent is to make our trac better searchable and reduce clutter. First, I went through the Patches Welcome milestone and marked tickets that in my opinion should be just closed: https://fedorahosted.org/sssd/report/35 These are tickets that either talk about enhancements to the local provider, do not have any useful information (example: a crash in the version we shipped in RHEL-6.1) or were simply filed as an idea many years ago but since then nobody stepped up to work on this ticket and nebody requested this work again, so the assumption is that nobody really needs that work. Feel free to go through this list and push back if you disagree. For tickets where nobody complains about closing them, I will close them in a week from now. If somebody will disagree about closing these tickets, we can always reopen them.. As a next step if Trac cleanup, I will go through the 'Future releases' milestone and propose some tickets for moving into 'Patches welcome' or being closed right away.

2 3

[sssd PR#83][opened] TESTS: Check new line at end of file
by fidencio 23 Nov '16

23 Nov '16

URL: https://github.com/SSSD/sssd/pull/83 Author: lslebodn Title: #83: TESTS: Check new line at end of file Action: opened PR body: """ @spbnick Do you have a better idea how to filter out exceptions in `src/tests/whitespace_test` """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/83/head:pr83 git checkout pr83

1 19

[sssd PR#80][opened] SYSDB: Sudorule without a sudoUser returns EINVAL
by fidencio 23 Nov '16

23 Nov '16

URL: https://github.com/SSSD/sssd/pull/80 Author: celestian Title: #80: SYSDB: Sudorule without a sudoUser returns EINVAL Action: opened PR body: """ This patch solved a regression caused by the recent patches to lowercase sudoUser -- in case sudoUser is missing completely, we abort the processing of this rule and all others. With this patch, we return EINVAL and gracefully skip the malgormed rule instead. Resolves: https://fedorahosted.org/sssd/ticket/3241 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/80/head:pr80 git checkout pr80

1 11

[sssd PR#82][opened] KRB5: Remove spurious warning in logs
by fidencio 22 Nov '16

22 Nov '16

URL: https://github.com/SSSD/sssd/pull/82 Author: lslebodn Title: #82: KRB5: Remove spurious warning in logs Action: opened PR body: """ The option krb5_map_user is empty by default. Therefore we should not confuse users wih warning (Fri Nov 15 09:58:49 2016) [sssd[be[example.com]]] [parse_krb5_map_user] (0x0200): Warning: krb5_map_user is empty! """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/82/head:pr82 git checkout pr82

1 5

[sssd PR#81][opened] Please see the commit message, the fix is hopefully simple
by fidencio 22 Nov '16

22 Nov '16

URL: https://github.com/SSSD/sssd/pull/81 Author: jhrozek Title: #81: Please see the commit message, the fix is hopefully simple Action: opened PR body: """ None """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/81/head:pr81 git checkout pr81

1 12

[Q] t3222 sssd still showing ipa user after removed from last group
by Petr Cech 21 Nov '16

21 Nov '16

Hi all, I came back to ticket #3222 "sssd still showing ipa user after removed from last group" [1]. And I have new knowledge. But I still do not see the light at the end of the tunnel. [1] https://fedorahosted.org/sssd/ticket/3222 I attached patch which enables some basic debug on using of memcache. And two reproducers (with and without memcache) which are based on reproducer written in ticket. If we use memcache, the issue occurs only sometimes. The difference between both cases is mixed state of switch after sss_nss_mc_getgrnam() call in _nss_sss_getgrnam_r() function. Note: code says (for default case): /* if using the mmaped cache failed, * fall back to socket based comms */ Could anyone help, please? The report is: #--- WRONG [root@mirach sssd]# date && getent group testgroup Wed Nov 9 16:01:05 CET 2016 >>> [A] record not found (time[1478703665]) >>> [B] record not found (time[1478703665]) testgroup:*:1703800674: Number of members added 1 [root@mirach sssd]# sss_cache -UG && date && getent group testgroup Wed Nov 9 16:01:07 CET 2016 >>> [A] record not found (time[1478703667]) >>> [B] default (time[1478703667]) testgroup:*:1703800674:testuser Number of members removed 1 [root@mirach sssd]# sss_cache -UG && date && getent group testgroup Wed Nov 9 16:01:09 CET 2016 >>> mc record expires at [1478703967] | now [1478703669] >>> [A] MC used (time[1478703669]) testgroup:*:1703800674:testuser [root@mirach sssd]# grep '>>>' *.log sssd_nss.log:(Wed Nov 9 16:01:06 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703966] | now [1478703666] | delta [300] sssd_nss.log:(Wed Nov 9 16:01:06 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [0] sssd_nss.log:(Wed Nov 9 16:01:07 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703967] | now [1478703667] | delta [300] sssd_nss.log:(Wed Nov 9 16:01:07 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [1] #--- RIGHT [root@mirach sssd]# date && getent group testgroup Wed Nov 9 15:56:54 CET 2016 >>> [A] record not found (time[1478703414]) >>> [B] record not found (time[1478703414]) testgroup:*:1703800674: Number of members added 1 [root@mirach sssd]# sss_cache -UG && date && getent group testgroup Wed Nov 9 15:56:56 CET 2016 >>> [A] default (time[1478703416]) >>> [B] default (time[1478703416]) testgroup:*:1703800674:testuser Number of members removed 1 [root@mirach sssd]# sss_cache -UG && date && getent group testgroup Wed Nov 9 15:56:58 CET 2016 >>> [A] record not found (time[1478703418]) >>> [B] record not found (time[1478703418]) testgroup:*:1703800674: [root@mirach sssd]# grep '>>>' *.log sssd_nss.log:(Wed Nov 9 15:56:54 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703714] | now [1478703414] | delta [300] sssd_nss.log:(Wed Nov 9 15:56:54 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [0] sssd_nss.log:(Wed Nov 9 15:56:56 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703716] | now [1478703416] | delta [300] sssd_nss.log:(Wed Nov 9 15:56:56 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [1] sssd_nss.log:(Wed Nov 9 15:56:58 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703718] | now [1478703418] | delta [300] sssd_nss.log:(Wed Nov 9 15:56:58 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [0] Regards -- Petr^4 Čech

3 3

[sssd PR#77][opened] Qualify ghost users with RFC2307bis and ldap_nesting_level=0
by fidencio 16 Nov '16

16 Nov '16

URL: https://github.com/SSSD/sssd/pull/77 Author: jhrozek Title: #77: Qualify ghost users with RFC2307bis and ldap_nesting_level=0 Action: opened PR body: """ None """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/77/head:pr77 git checkout pr77

1 3

[RFC] Socket-activate responders
by Fabiano Fidêncio 16 Nov '16

16 Nov '16

People, I've spent some time looking at the code and trying to understand what are the needed changes in order to have this task done. I'll start by writing down how things are working nowadays, what we want to achieve, what are the parts that will need to be touched and what are the steps that I'm going to take. Please, keep in mind that I may have a wrong (or at least not so clear) understanding of all these points that I'm about to explain and in case I made some mistake feel free to jump in and correct me. Also, whatever we sum up from this email will be written down in our DesignFeatures page. Let's start ... How things work nowadays: ---------------------------------------- Nowadays all the services are started and taken care by the monitor. It basically means that the monitor checks which are the services listed to be started, starts those and registers them in order to relay them signals coming from our tools. Here I'm not sure whether the monitor relays signals from something else but the tools, but doesn't seem to be case (and please, correct me in case I'm wrong). What we want to achieve: ------------------------------------- While my personal desire is to start slowly killing the monitor, that's not going to be case right now. We don't want to do any change in the code that wouldn't also contemplate platforms where systemd is not available. That being said, let's move to the important part ... Here what we want to achieve is to have all responders (at least for now, yes, just the responders) socket-activatable as some of them don't actually have to be running all the time (that's the case, for example, of the ssh, sudo and ifp responders). We also have to keep into consideration that _any_ change in behaviour should _not_ happen, which means that we still have to honor our compromise with sssd.conf and still make the responders manually activated there to start and be running from the moment sssd is running (as we do nowadays). How we plan to achieve our goal: ----------------------------------------------- Some parts I have a pretty clear idea on what to do, some others not that much. The basic idea is to take as much advantage of systemd machinery as we can and "remove" as much duties as possible from the monitor. Let's go through this by parts ... - Starting the service: the idea is to have a systemd unit for each of the responders. Whether these units will be automatically generated by us is a detail that doesn't worth attention right now. Let's take a look on what the unit will look like: [Unit] Description=SSSD @responder@ service provider [Install] Also=sssd-@responder@.socket [Service] ExecStart==@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files Requires=sssd.service PartOf=sssd.service There's two options that deserve some explanation of their usage here: -- "Requires=sssd.service": This option guarantees that sssd will be up when any of the responders are up. Considering that the providers part won't be changed, those will still be initializated synchronously by the monitor and only then notify init that its start up finished, which also mean that the providers' sbus socket will be up. -- "PartOf=sssd.service": This options guarantees that when sssd.service is restarted/stoped all the responders' services will be restarted/stopped accordingly. - Relaying signals: seems the best approach for this in order to replace the registration currently done by the monitor, is to create a named bus for each of the responders so the tools could talk directly to them. By "named bus for each responder" I understand that's a pipe, named sbus-@responder@ that will be used to send the dbus message through it. It would require to adapt the tools code to actually check whether the sbus-@responder@ pipe exists and then send the message, as we won't have a list of the running responders, which may increase the iterations to send a message but I do believe wouldn't hurt us too much due to the small number of responders we have. It will also help tools to be able to set different debug levels for each responder. Seems, at least for me, that doing these steps we are covered with respect to what we have nowadays. Does someone think that we are missing something? What? Please, try to explain in the same way you would explain to a 5 years old kid :-) Coding plan: ------------------ My current plan is to start implementing this whole thing by creating the named bus for each responder and have the communication between the responders and the tools working. Next step will be to actually have the responders started on demand by using socket-activation. And the very last step will be to make sure we can have the responders always running when they're listed in the sssd.conf. I'm not comfortable on giving any estimation about when we will have it done, mainly because I'd like to hear the feedback about this from others in the team. Looking forward for your reading back from you! Best Regards, -- Fabiano Fidêncio

2 3

[sssd PR#68][opened] MAN: Document different defaults for AD provider
by fidencio 15 Nov '16

15 Nov '16

URL: https://github.com/SSSD/sssd/pull/68 Author: justin-stephenson Title: #68: MAN: Document different defaults for AD provider Action: opened PR body: """ Update man pages for any AD provider config options that differ from ldap/krb5 provider back-end defaults. Resolves: https://fedorahosted.org/sssd/ticket/3214 I would appreciate any suggestions on improving the wording, I was hoping to be informative but concise. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/68/head:pr68 git checkout pr68

1 21

[sssd PR#78][opened] ipa: Nested netgroups do not work
by fidencio 14 Nov '16

14 Nov '16

URL: https://github.com/SSSD/sssd/pull/78 Author: mzidek-rh Title: #78: ipa: Nested netgroups do not work Action: opened PR body: """ We lowercase the keys to the hash table used to store netgroups but do not lowercase it when reading the table. This results in nested netgroups not being found when they should and the processing fails. The lowercasing does not seem to be necessary anymore (not sure if it ever was) so we can skip it. Resolves: https://fedorahosted.org/sssd/ticket/3159 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/78/head:pr78 git checkout pr78

1 8

[sssd PR#65][opened] Fixing of nitpicks
by fidencio 14 Nov '16

14 Nov '16

URL: https://github.com/SSSD/sssd/pull/65 Author: celestian Title: #65: Fixing of nitpicks Action: opened PR body: """ Hello, there are two simple patches. I found those things during static analysis of SSSD code. Petr """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/65/head:pr65 git checkout pr65

1 10

[sssd PR#53][opened] Fixes in the config API related to secrets responder
by fidencio 11 Nov '16

11 Nov '16

URL: https://github.com/SSSD/sssd/pull/53 Author: fidencio Title: #53: Fixes in the config API related to secrets responder Action: opened PR body: """ Those fixes were suggested by Lukaš in the following thread: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.… Changes: 28fa419 (Fabiano Fidêncio, 11 minutes ago) SECRETS: Add allowed_sec_users_options There are options (the proxying related ones) that only apply to the secrets' subsections. In order to make config API able to catch those, let's create a new section called allowed_sec_users_options) and move there these proxying options. Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> 2aed214 (Fabiano Fidêncio, 2 hours ago) SECRETS: Fix secrets rule in the allowed sections We have been matching an invalid subsection of the secrets' section, like: [secrets/users] Let's ensure that we only match the following cases: [secrets] [secrets/users/[0-9]+?] 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/53/head:pr53 git checkout pr53

2 23

[sssd PR#74][opened] IPA/AD: check auth ctx before using it
by fidencio 10 Nov '16

10 Nov '16

URL: https://github.com/SSSD/sssd/pull/74 Author: sumit-bose Title: #74: IPA/AD: check auth ctx before using it Action: opened PR body: """ In e6b6b9fa79c67d7d2698bc7e33d2e2f6bb53d483 a feature was introduced to set the 'canonicalize' option in the system-wide Kerberos configuration according to the settings in SSSD if the AD or IPA provider were used. Unfortunately the patch implied that the auth provider is the same as the id provider which might not always be the case. A different auth provider caused a crash in the backend which is fixed by this patch. Resolves https://fedorahosted.org/sssd/ticket/3234 I tried to add an integration test to see if SSSD can start with a mixed configuration but the AD provider tries to set some SASL parameters which requires e.g. an existing keytab which is afaik currently not available in the integration test. Since this issue it easy to reproduce manually (start SSSD with id_provder=ad and auth_provider=krb5) I hope it is acceptable that an integration test can be added later when the infrastructure for AD provider tests is available? """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/74/head:pr74 git checkout pr74

1 10

Nested netgroups with IPA provider
by Michal Židek 10 Nov '16

10 Nov '16

Hi, this is continuation of discussion about pull request 51 and associated tickets. For context, see: https://github.com/SSSD/sssd/pull/59 https://fedorahosted.org/sssd/ticket/3159 https://fedorahosted.org/sssd/ticket/3116 The FreeIPA UQE guys added upstream test for this issue because we do not have upstream CI tests in SSSD with IPA provider yet and this bug is not present in the plain LDAP. We use hash tables to store members of netgroups while processing netgroups (and creating the netgroup triples). The netgroup names are lowercased before they are stored in the hash table. The reason for this normalization is unknown to me. FreeIPA only creates lowercased netgroup names, so lowercasing only affects the attribute name (that is stored as prefix to the netgroup name in the hash table, and maybe it can happen that the attribute name can be stored in different cases at some point, which would explain why we lower case it, however I was not able to confirm if this is the case). When we read the hash table, we do not lowercase the keys, so the nested netgroups are not found and this is the reason why the bug appears. The patch in PR 51 lower cases the keys before reading the hash table and the bug does not appear after that. Lukas thinks however that this is not good approach, because there should be no need for the lower casing in the first place. Patch that removes the lower casing before adding the keys to htable should also fix the issue. I did not send the patch with this approach, because I was not sure why the lowercasing happens in the first place and I know that lowercasing is not harmful for the IPA netgroups, so I find it safer to use the approach in the PR 51 especially while we do not have good code coverage for IPA provider, however as I mentioned in the PR 51, I am looking for opinions on this. Thanks, Michal

3 5

[sssd PR#59][opened] ipa_netgroups: Lowercase key to htable
by fidencio 10 Nov '16

10 Nov '16

URL: https://github.com/SSSD/sssd/pull/59 Author: mzidek-rh Title: #59: ipa_netgroups: Lowercase key to htable Action: opened PR body: """ Fixes: https://fedorahosted.org/sssd/ticket/3116 We lowercase the search key when storing entries into the hash table, but do not do it when we search for them. As a result we were not able to find netgroup by DN. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/59/head:pr59 git checkout pr59

1 33

about letting the responder choose the sysdb optimization level
by Jakub Hrozek 09 Nov '16

09 Nov '16

Hi, I would like to ask for opinions about: https://fedorahosted.org/sssd/ticket/3126 The basic idea is that the responder would choose what kind of optimization would the back end perform when saving the sysdb entries. Requests that just return information might choose to optimize very aggressively (using modifyTimestamp) and requests that actually authenticate or authorize the user might choose to not optimize at all to avoid issues like the ones we saw with virtual attributes that don't bump the modifyTimestamp attribute at all. On the responder side, this is quite easy, just send an additional flag during the responder request. It's the provider part I'm not so sure about, because there the optimizations are performed at the sysdb level. So far I can only think about extending sysdb_transaction_start() (or providing sysdb_opt_transaction_start and letting the old sysdb_transaction_start default to no optimization) which would internally keep track of the active transaction and the optimization we want to perform. Since only sssd_be is the cache writer and there is only one cache per domain. Additionally, we would have to keep the transaction optimization level around in some context until the request bubbles from the data provider handler to actually saving the transaction. I don't I hope this won't be too messy, but since the requests are asynchronous, so far I don't see any way around it. The only thing that might be less messy in the long term is to provide a bit more generic structure ("request status") that would so far only include the optimization level and later might be extended to include e.g. intermediate data. But on the other hand, I'm not sure I have thought about passing the data between requests hard enough to design this properly. Should I? Any other opinions? Thoughts?

3 3

[Q] t3222 sssd still showing ipa user after removed from last group
by Petr Cech 09 Nov '16

09 Nov '16

Hi all, I came back to ticket #3222 "sssd still showing ipa user after removed from last group" [1]. And I have new knowledge. But I still do not see the light at the end of the tunnel. [1] https://fedorahosted.org/sssd/ticket/3222 I attached patch which enables some basic debug on using of memcache. And two reproducers (with and without memcache) which are based on reproducer written in ticket. If we use memcache, the issue occurs only sometimes. The difference between both cases is mixed state of switch after sss_nss_mc_getgrnam() call in _nss_sss_getgrnam_r() function. Note: code says (for default case): /* if using the mmaped cache failed, * fall back to socket based comms */ Could anyone help, please? The report is: #--- WRONG [root@mirach sssd]# date && getent group testgroup Wed Nov 9 16:01:05 CET 2016 >>> [A] record not found (time[1478703665]) >>> [B] record not found (time[1478703665]) testgroup:*:1703800674: Number of members added 1 [root@mirach sssd]# sss_cache -UG && date && getent group testgroup Wed Nov 9 16:01:07 CET 2016 >>> [A] record not found (time[1478703667]) >>> [B] default (time[1478703667]) testgroup:*:1703800674:testuser Number of members removed 1 [root@mirach sssd]# sss_cache -UG && date && getent group testgroup Wed Nov 9 16:01:09 CET 2016 >>> mc record expires at [1478703967] | now [1478703669] >>> [A] MC used (time[1478703669]) testgroup:*:1703800674:testuser [root@mirach sssd]# grep '>>>' *.log sssd_nss.log:(Wed Nov 9 16:01:06 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703966] | now [1478703666] | delta [300] sssd_nss.log:(Wed Nov 9 16:01:06 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [0] sssd_nss.log:(Wed Nov 9 16:01:07 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703967] | now [1478703667] | delta [300] sssd_nss.log:(Wed Nov 9 16:01:07 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [1] #--- RIGHT [root@mirach sssd]# date && getent group testgroup Wed Nov 9 15:56:54 CET 2016 >>> [A] record not found (time[1478703414]) >>> [B] record not found (time[1478703414]) testgroup:*:1703800674: Number of members added 1 [root@mirach sssd]# sss_cache -UG && date && getent group testgroup Wed Nov 9 15:56:56 CET 2016 >>> [A] default (time[1478703416]) >>> [B] default (time[1478703416]) testgroup:*:1703800674:testuser Number of members removed 1 [root@mirach sssd]# sss_cache -UG && date && getent group testgroup Wed Nov 9 15:56:58 CET 2016 >>> [A] record not found (time[1478703418]) >>> [B] record not found (time[1478703418]) testgroup:*:1703800674: [root@mirach sssd]# grep '>>>' *.log sssd_nss.log:(Wed Nov 9 15:56:54 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703714] | now [1478703414] | delta [300] sssd_nss.log:(Wed Nov 9 15:56:54 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [0] sssd_nss.log:(Wed Nov 9 15:56:56 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703716] | now [1478703416] | delta [300] sssd_nss.log:(Wed Nov 9 15:56:56 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [1] sssd_nss.log:(Wed Nov 9 15:56:58 2016) [sssd[nss]] [sss_mmap_set_rec_header] (0x0010): >>> MC STORE expiration [1478703718] | now [1478703418] | delta [300] sssd_nss.log:(Wed Nov 9 15:56:58 2016) [sssd[nss]] [sss_mmap_cache_gr_store] (0x0010): >>> MC STORE [testgroup] [300] members [0] Regards -- Petr^4 Čech

1 0

[sssd PR#72][opened] Remove two unused methods from monitor's sbus interface
by fidencio 09 Nov '16

09 Nov '16

URL: https://github.com/SSSD/sssd/pull/72 Author: jhrozek Title: #72: Remove two unused methods from monitor's sbus interface Action: opened PR body: """ None """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/72/head:pr72 git checkout pr72

1 4

[sssd PR#76][comment] AD: Fix crash in AD subdomain reinit
by fidencio 09 Nov '16

09 Nov '16

URL: https://github.com/SSSD/sssd/pull/76 Title: #76: AD: Fix crash in AD subdomain reinit lslebodn commented: """ Closing as duplicate of PR #74 """ See the full comment at https://github.com/SSSD/sssd/pull/76#issuecomment-259370381

1 0

[sssd PR#76][closed] AD: Fix crash in AD subdomain reinit
by fidencio 09 Nov '16

09 Nov '16

URL: https://github.com/SSSD/sssd/pull/76 Author: justin-stephenson Title: #76: AD: Fix crash in AD subdomain reinit Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/76/head:pr76 git checkout pr76

1 0

[sssd PR#76][+Rejected] AD: Fix crash in AD subdomain reinit
by fidencio 09 Nov '16

09 Nov '16

URL: https://github.com/SSSD/sssd/pull/76 Title: #76: AD: Fix crash in AD subdomain reinit Label: +Rejected

1 0

[sssd PR#76][comment] AD: Fix crash in AD subdomain reinit
by fidencio 09 Nov '16

09 Nov '16

URL: https://github.com/SSSD/sssd/pull/76 Title: #76: AD: Fix crash in AD subdomain reinit sumit-bose commented: """ PR #74 has the same fix and a similar forx for the IPA provider as well. I'm fine with revoking #74 if the fix for the IPA provider is added here as well. """ See the full comment at https://github.com/SSSD/sssd/pull/76#issuecomment-259349272

1 0

[sssd PR#76][comment] AD: Fix crash in AD subdomain reinit
by fidencio 09 Nov '16

09 Nov '16

URL: https://github.com/SSSD/sssd/pull/76 Title: #76: AD: Fix crash in AD subdomain reinit celestian commented: """ ok to test """ See the full comment at https://github.com/SSSD/sssd/pull/76#issuecomment-259348408

1 0

[sssd PR#76][comment] AD: Fix crash in AD subdomain reinit
by fidencio 08 Nov '16

08 Nov '16

URL: https://github.com/SSSD/sssd/pull/76 Title: #76: AD: Fix crash in AD subdomain reinit centos-ci commented: """ Can one of the admins verify this patch? """ See the full comment at https://github.com/SSSD/sssd/pull/76#issuecomment-259315385

1 0

[sssd PR#76][comment] AD: Fix crash in AD subdomain reinit
by fidencio 08 Nov '16

08 Nov '16

URL: https://github.com/SSSD/sssd/pull/76 Title: #76: AD: Fix crash in AD subdomain reinit centos-ci commented: """ Can one of the admins verify this patch? """ See the full comment at https://github.com/SSSD/sssd/pull/76#issuecomment-259315383

1 0

[PATCH SET] SYSDB: Adding message to inform about cache
by Petr Cech 08 Nov '16

08 Nov '16

Hello list, I am solving ticket [1] now. There are three points mentioned. A have prepared patches for the first two. I would like to ask anybody it is right or if I miss something. The third point is about full LDIFF in special debug level. What does it mean 'special debug level'? Is it new option, for example? [1] https://fedorahosted.org/sssd/ticket/3060 Regards -- Petr^4 Čech

4 45

[sssd PR#73][opened] AD_PROVIDER: Enabled subdomains (1.13)
by fidencio 08 Nov '16

08 Nov '16

URL: https://github.com/SSSD/sssd/pull/73 Author: celestian Title: #73: AD_PROVIDER: Enabled subdomains (1.13) Action: opened PR body: """ This is backport of https://fedorahosted.org/sssd/ticket/2828 to 1.13. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/73/head:pr73 git checkout pr73

1 12

[sssd PR#43][opened] SUDO: Adding user name alias to sudoRule filter
by fidencio 08 Nov '16

08 Nov '16

URL: https://github.com/SSSD/sssd/pull/43 Author: celestian Title: #43: SUDO: Adding user name alias to sudoRule filter Action: opened PR body: """ This patch adds another value to sudoUser attribute of sudoRule filter. The value is 'user alias' which means it is cased version of user (in domains where it matters). Resolves: https://fedorahosted.org/sssd/ticket/3203 ----- This is complement to #39 . The idea is some domains are case sensitive and another not. If we would like to search ```sudoRules``` we need handle user names. With this patch we add user name alias (case sensitive form) of user name to the ```sudoRule``` filter. Another point is we could save both forms of user name to cached ```sudoRules```. It could be extension of this patch. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/43/head:pr43 git checkout pr43

2 53

[sssd PR#71][opened] MONITOR: Do not set up watchdog for monitor
by fidencio 08 Nov '16

08 Nov '16

URL: https://github.com/SSSD/sssd/pull/71 Author: jhrozek Title: #71: MONITOR: Do not set up watchdog for monitor Action: opened PR body: """ It makes little sense to set up watchdog for monitor because there is no entity that would restart the monitor. Therefore we should disable the watchdog for monitor process. Resolves: https://fedorahosted.org/sssd/ticket/3232 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/71/head:pr71 git checkout pr71

1 4

[PATCHES] views: properly override group member names
by Sumit Bose 08 Nov '16

08 Nov '16

Hi, this is my suggestion to solve https://fedorahosted.org/sssd/ticket/2948 "Handle overriden name of members in the memberUid attribute". The first two patches are for the IPA provider and make sure that all ghost members in a group get resolved because otherwise we cannot determine if the name is overridden or not. This adds an overhead to group lookups, especially for larger groups but I think it is an requirement which cannot be skipped. The third patch adds a sysdb call to recursively resolve all user-members of a group. Since the groups in SSSD's cache are hierarchically organized the member attribute only contains direct user and group members. To get all users the group members must be resolved recursively. Finally the forth patch applies the code-path which is already used for non-default views to the default case as well and adds a new list of members, with correctly overridden names (hopefully :-) which is then used in fill_grmem(). This adds some overhead to the overall group processing in the NSS responder (as can be seen in the test changes because the members are returned in different order in some cases). But I think because the of memory cache this is acceptable and might even help to remove the memberuid attribute in future and make the memberof plugin simpler. I worked on an alternative approach as well which tried to make the memberof plugin aware of the defaultOverrideName attribute. My wip tree is at https://fedorapeople.org/cgit/sbose/public_git/sssd.git/log/?h=memberof_def… but so far it does not work properly. Additionally I would prefer to not touch the memberof plugin. bye, Sumit

3 20

Announcing SSSD 1.14.2
by Jakub Hrozek 07 Nov '16

07 Nov '16

=== SSSD 1.14.2 === The SSSD team is proud to announce the release of version 1.14.2 of the System Security Services Daemon. As always, the source is available from https://fedorahosted.org/sssd RPM packages will be made available for Fedora shortly. == Feedback == Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users == Highlights == * Several more regressions caused by cache refactoring to use qualified names internally were fixed, including a regression that prevented the krb5_map_user option from working correctly. * A regression when logging in with a smart card using the GDM login manager was fixed * SSSD now removes the internal timestamp on startup cache when the persistent cache is removed. This enables admins to follow their existing workflow of just removing the persistent cache and start from a fresh slate * Several fixes to the sssd-secrets responder are present in this release * A bug in the autofs responder that prevented automounter maps from being returned when sssd_be was offline was fixed * A similar bug in the NSS responder that prevented netgroups from being returned when sssd_be was offline was fixed * Disabling the netlink integration can now be done with a new option disable_netlink. Previously, the netlink integration could be disabled with a sssd command line switch, which is being deprecated in this release. * The internal watchdog no longer kills sssd processes in case time shifts during sssd runtime * The fail over code is able to cope with concurrent SRV resolution requests better in this release * The proxy provider gained a new option proxy_max_children that allows the administrator to control the maximum number of child helper processes that authenticate users with auth_provider=proxy * The InfoPipe D-Bus responder exports the UUIDs of user and group objects through a uniqueID property == Packaging Changes == * The private pipe directory permissions were changed from 0700 to 0750. The restrictive permissions we causing SELinux dac_override denials * The Python packages for python2 were renamed from python-package to python2-package with backwards-compatible Provides and Obsoletes * The sssd-common subpackage contains a new manual page sssd-secrets(5) * The sssd-tools subpackage explicitly Requires /sbin/service on platforms that don't support systemd in order to be able to restart sssd from the sssctl tool == Documentation Changes == * The kill_service option that was no longer useful after we moved from in-process pings to watchdog was removed * The --disable-netlink sssd(8) command-line option was removed in favor of [sssd] section option disable_netlink * The proxy_max_children option was added. Please see the highlights section for more details. * The sssd-secrets responder gained a man page in this release. * Two new options containers_nest_level and max_secrets options were added to the sssd-secrets responder. The former allows the administrator to configure the maximum nesting level of secrets containers, the latter allows the administrator to configure the maximum number of secrets that can be stored. Please note that both option apply to the local secrets provider only. * The sssd-ldap man page didn't specify different default for user and group name LDAP attribute default for the AD provider. This documentation bug was fixed. == Tickets Fixed == https://fedorahosted.org/sssd/ticket/2813 man page for sss_override command provides irrelevant information for --debug option https://fedorahosted.org/sssd/ticket/2841 sssd stores and returns incorrect information about empty netgroup (ldap-server: 389-ds) https://fedorahosted.org/sssd/ticket/3051 Move the diag_cmd option so that it's usable by the watchdog. https://fedorahosted.org/sssd/ticket/3052 Remove the no longer used kill_service command https://fedorahosted.org/sssd/ticket/3053 The sssd-secrets responder needs a manpage https://fedorahosted.org/sssd/ticket/3054 Create integration tests for the sssd-secrets responder https://fedorahosted.org/sssd/ticket/3056 The sssctl tool should restart the service with systemd's dbus API https://fedorahosted.org/sssd/ticket/3107 Python SSSD Config API deletes an item during iteration https://fedorahosted.org/sssd/ticket/3123 Netgroup resolution doesn't work offline https://fedorahosted.org/sssd/ticket/3125 secrets responder throws an internal error when trying to delete a non-existent secret https://fedorahosted.org/sssd/ticket/3127 SSSD qualifies principal twice in IPA-AD trust if the principal attribute doesn't exist on the AD side https://fedorahosted.org/sssd/ticket/3128 throw away the timestamp cache if re-initializing the persistent cache https://fedorahosted.org/sssd/ticket/3134 sssd is not able to authenticate with alias https://fedorahosted.org/sssd/ticket/3137 secrets: creating a secret in a container doesn't work https://fedorahosted.org/sssd/ticket/3140 autofs map resolution doesn't work offline https://fedorahosted.org/sssd/ticket/3142 expose disabling the netlink support as a sssd.conf option https://fedorahosted.org/sssd/ticket/3143 selinux avc denial for vsftp login as ipa user https://fedorahosted.org/sssd/ticket/3145 Update sssd-sudo man page to reflect native sudo support https://fedorahosted.org/sssd/ticket/3154 sssd exits if clock is adjusted backwards after boot https://fedorahosted.org/sssd/ticket/3163 resolving IPA nested user group is broken in 1.14 https://fedorahosted.org/sssd/ticket/3165 login using gdm calls for gdm-smartcard when smartcard authentication is not enabled https://fedorahosted.org/sssd/ticket/3167 SECRETS: Deleting a container that has children should fail https://fedorahosted.org/sssd/ticket/3168 secrets: Add a configurable depth limit for containers https://fedorahosted.org/sssd/ticket/3172 Access denied for user when access_provider = krb5 is set in sssd.conf https://fedorahosted.org/sssd/ticket/3173 unable to create group in sssd cache https://fedorahosted.org/sssd/ticket/3174 Clock skew makes SSSD return System Error https://fedorahosted.org/sssd/ticket/3175 sss_groupshow does not work https://fedorahosted.org/sssd/ticket/3178 unable to add local user in sssd to a group in sssd https://fedorahosted.org/sssd/ticket/3179 sss_override fails to export https://fedorahosted.org/sssd/ticket/3180 sss_cache -r option does not print error message if more than one argument is supplied https://fedorahosted.org/sssd/ticket/3181 libwbclient-sssd: update interface to version 0.13 https://fedorahosted.org/sssd/ticket/3184 sss_groupshow <user> fails with error "No such group in local domain. Printing groups only allowed in local domain" https://fedorahosted.org/sssd/ticket/3185 SSSD goes offline when the LDAP server returns sizelimit exceeded https://fedorahosted.org/sssd/ticket/3188 krb5_map_user doesn't seem effective anymore https://fedorahosted.org/sssd/ticket/3194 [RFE] Make GETSIDBYNAME and GETORIGBYNAME request aware of UPNs and aliases https://fedorahosted.org/sssd/ticket/3205 Typo In SSSD-AD Man Page https://fedorahosted.org/sssd/ticket/3207 SSSD logs error upon adding [secrets] section. https://fedorahosted.org/sssd/ticket/3212 secrets: 500 internal server error when proxy is defined but not running https://fedorahosted.org/sssd/ticket/3213 IPA: Uninitialized variable during subdomain check == Detailed Changelog == Fabiano Fidêncio (24): * PROXY: Use the fqname when converting to lowercase * SYSDB: Rework sysdb_cache_connect() * SYSDB: Remove the timestamp cache for a newly created cache * SECRETS: Return ENOENT when_deleting a non-existent secret * PROXY: Remove lowercase attribute from save_user() * PROXY: Remove cache_timeout attribute from save_user() * PROXY: Remove cache_timeout attribute from save_group() * PROXY: Mention that save_user()'s parameters are already qualified * PROXY: Share common code of save_{group,user}() * BUILD: Add a few more targets for intg tests * BUILD: Clean up prerelease targets * BUILD: Fix typo in intgcheck-run rule * MONITOR: Remove leftovers from diag_cmd * MONITOR: Remove leftovers from kill_service * SECRETS: Search by the right type when checking containers * SECRETS: Don't remove a container when it has children * CONFIG: Add secrets responder to the allowed sections * CONFIG: Add secrets provider options * SECRETS: Make functions from local.c static * SECRETS: Use a tmp_context on local_db_check_containers() * SECRETS: Add a configurable depth limit for nested containers * SECRETS: Add a configurable limit of secrets that can be stored * TESTS: Remove a leftover debug message * TESTS: Fix check for py bindings in dlopen tests Jakub Hrozek (35): * Updating the version for the 1.14.2 release * CONFIG: selinux_provider is a valid provider type * CONFIG: session_provider does not exist anymore * IPA: Parse qualified names when guessing AD user principal * MONITOR: Remove the no longer used diag_cmd command * MONITOR: Remove the no longer used kill_service command * WATCHDOG: define and use _MAX_TICKS as 3 * SECRETS: Make internal function static * SECRETS: Make reading the config options more uniform * netlink: Don't define USE_GNU * MAN: Document the ldap_user_primary_group option * TOOLS: Fix a typo in groupadd() * KRB5: Send the output username, not internal fqname to krb5_child * KRB5: Return ERR_NETWORK_IO on clock skew * LDAP: Return partial results from adminlimit exceeded * TESTS: Add integration tests for the sssd-secrets * AUTOFS: Fix offline resolution of autofs maps * NSS: Fix offline resolution of netgroups * TESTS: Test offline netgroups resolution * tests: Add a regression test for upstream ticket #3131 * MAN: sssd-secrets documentation * CONFIG: List allowed secrets responder options * SECRETS: Add DEBUG messages to the sssd-secrets provider * SECRETS: Use a better data type for ret * SECRETS: Fix a typo in function name * SECRETS: Use HTTP error code 504 when a proxy server cannot be reached * IPA: Initialize a boolean control value * tests: Add tests for sidbyname NSS operation * tests: Add tests for getorig by UPN NSS op * BUILD: Detect the path of the "service" executable * BUILD: Only search for service in /sbin and /usr/sbin * BUILD: Not having /sbin/service is not fatal * RPM: Require initscripts on non-systemd platforms * sssctl: Fix a typo in preprocessor macro * Updating the translations for the 1.14.2 release Justin Stephenson (4): * MONITOR: Remove --disable-netlink command-line option * MONITOR: Add disable_netlink option * MAN: sssd-sudo manual update IPA native LDAP tree support * sss_cache: improve option argument handling Lukas Slebodnik (16): * sssd_netgroup.py: Resolve nested netgroups * BUILD: Allow to read private pipes for root * SPEC: Fix typo in Summary * SYSDB: Fix uninitialized scalar variable * BUILD: Remove leftover after sysdb refactoring * PROXY: Use right name in ldap filter * SYSDB: Fix error handling in sysdb_get_user_members_recursively * DEBUG: Apend line feed to messages from libsemanage * SYSDB: Suppress warning from clang static analyser * SDAP: Fix settig paging attribute in sdap_get_generic_ext_send * Remove double semicolon at the end of line * TESTS: Add simple test for double semicolon * SSSDConfig: Do not fail with nonexisting domains/services * SPEC: Rename python packages using macro %python_provide * BUILD: intgcheck need to fail if pytest fails * CI: Remove dlopen-test from valgrind blacklist Michal Židek (12): * TOOLS: sss_groupshow did not work * TESTS: sss_groupadd/groupshow regressions * TOOLS: use internal fqdn for DN * TESTS: Test for sss_user/groupmod -a * TOOLS: sss_mc_refresh_nested_group short/fqname usage * TESTS: Add FQDN variants for some tests * TOOLS: sss_override without name override * TEST: Add regression test for ticket #3179 * TOOLS: sss_groupshow fails to show MPG * TESTS: sss_groupshow with MPG * MAN: Typo in id mapping explanation * MAN: Wrong defaults for AD provider Pavel Březina (7): * watchdog: cope with time shift * dyndns: fix typo and unify ipa with ad debug message when off * failover: proceed normally when no new server is found * sss_override: improve --debug description * man page: fix language in debug level description * sssctl: use systemd D-Bus API * sssctl: call service with absolute path Petr Cech (4): * LDAP: Fixing of removing netgroup from cache * INTG: Adding support for netgroups to ldap_ent * INTG: Tests for ldap nested netgroups * PROXY: Adding proxy_max_children option Petr Čech (5): * SYSDB: Removing of unused parameter * TESTS: Fixing of 'const' warnings in sbus tests * MAKEFILE: Fixing CFLAGS in some tests * KRB5: Fixing FQ name of user in krb5_setup() * TESTS: Adding intg. tests on nested groups Sumit Bose (8): * sdap_initgr_nested_get_membership_diff: use fully-qualified names * p11: only set PKCS11_LOGIN_TOKEN_NAME if gdm-smartcard is used * p11: return a fully-qualified name * pam_sss: check PKCS11_LOGIN_TOKEN_NAME * PAM: call free only when memory is expected to be allocated * nss: allow UPNs in SSS_NSS_GETSIDBYNAME and SSS_NSS_GETORIGBYNAME * libwbclient-sssd: update interface to version 0.13 * LDAP: Removing of member link from group Thomas Equeter (1): * IFP: expose user and group unique IDs through DBus

3 4

[PATCH] SYSDB: Fix error handling in sysdb_get_user_members_recursively
by Lukas Slebodnik 07 Nov '16

07 Nov '16

ehlo, We should not ignore return values of functions. LS

3 4

Watchdog in the monitor process
by Jakub Hrozek 07 Nov '16

07 Nov '16

Hi, Currently the watchdog is enabled for all sssd processes, including the main sssd process. I admit I only realised that now that I was looking into one user report where upgrading the sssd database during package update took so long that the watchdog eventually killed the sssd process..oops.. So we can either relax the watchdog during operations that we know might take a very long time (like upgrading huge cache files) or remove it altogether. I’m leaning towards the second option and just don’t setup the watchdog at all. Does anyone see a reason to keep the watchdog for the monitor? I think the watchdog in the current form makes sense only for “worker” processes where the monitor listens for SIGCHLD signals and restarts the services. I think for the monitor process it would make more sense to leverage some systemd functionality rather than kill itself :-)

3 2

[sssd PR#60][opened] Document ad_access_filter search for nested groups
by fidencio 03 Nov '16

03 Nov '16

URL: https://github.com/SSSD/sssd/pull/60 Author: taupehat Title: #60: Document ad_access_filter search for nested groups Action: opened PR body: """ Short doc fix and example to demonstrate how to ensure ad_access_filter includes nested group membership. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/60/head:pr60 git checkout pr60

1 23

[sssd PR#49][opened] Try to match multiple results from an AD initgroups request against domain's search bases, too
by fidencio 03 Nov '16

03 Nov '16

URL: https://github.com/SSSD/sssd/pull/49 Author: jhrozek Title: #49: Try to match multiple results from an AD initgroups request against domain's search bases, too Action: opened PR body: """ This is a proposed way of solving https://fedorahosted.org/sssd/ticket/3199. It is not complete, because there is no integration test, the commit message sucks and in general I'm not sure about the approach. But the problem is that if a search for a user returns multiple results (which is the case with nested child domains and GC in use), then we only try to match against a candidate base DN derived from the domains's name. This works in case the domain name is the same as the AD forest name, but not otherwise. Thefore, the patch tries to also take a look at the domain's search base and match against that as a fallback. My questions are: - is this a good idea at all? - should we loop across all search bases? - shouldn't we revert the order and first try to match the search base and only then the domain name? """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/49/head:pr49 git checkout pr49

1 25

[sssd PR#62][opened] PAM: add pam_response_filter option
by fidencio 02 Nov '16

02 Nov '16

URL: https://github.com/SSSD/sssd/pull/62 Author: sumit-bose Title: #62: PAM: add pam_response_filter option Action: opened PR body: """ Currently the main use-case for this new option is to not set the KRB5CCNAME environment varible for services like 'sudo-i'. Resolves https://fedorahosted.org/sssd/ticket/2296 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/62/head:pr62 git checkout pr62

1 20

Should we use VMs or containers for (some) tests?
by Jakub Hrozek 01 Nov '16

01 Nov '16

Hi, I'm currently working on integration tests for the 'files' provider and during this work I started to feel we are pushing the boundaries around our test infrastructure already quite a bit. When SSSD talks over network to a server, then we're more or less okay, but for some parts of SSSD, like the files provider, we have to mock a lot of pieces and the end result is that we are testing something that resembles the target system, but probably has its own bugs. Additionally, we can't run some tests at all (anything against IPA) and I suspect we'll be running into this sort of a problem even more in the future. So I'm interested in hearing what are other's thoughts on exploring how to run some of our tests in a privileged environment, either in a VM or in a container? Our current tests have the big advantage of being able to provision a test locally in a screen session, but maybe something similar would be possible by e.g. running a screen in a container and attaching to its tty.. And for "simple" tests like LDAP provider we could keep the current infrastructure around.

4 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel November 2016