January 2017 - sssd-devel - Fedora mailing-lists

[sssd PR#132][opened] Add "Wants=" to sssd unit and avoid PAC responder to be always running
by fidencio 02 Jan '20

02 Jan '20

URL: https://github.com/SSSD/sssd/pull/132 Author: fidencio Title: #132: Add "Wants=" to sssd unit and avoid PAC responder to be always running Action: opened PR body: """ The first patch changes the current logic of having the services' sockets disabled by default as it adds a "Wants=" to the sssd unit file, making all the services' sockets enabled by the moment sssd service is enabled. The second patch takes advantage of the first patch and avoids running PAC responder in case its socket is active, leaving the service to be socket-activated when needed. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/132/head:pr132 git checkout pr132

3 40

[sssd PR#128][opened] Fix group renaming issue when "id_provider = ldap" is set
by fidencio 25 Apr '18

25 Apr '18

URL: https://github.com/SSSD/sssd/pull/128 Author: fidencio Title: #128: Fix group renaming issue when "id_provider = ldap" is set Action: opened PR body: """ Those two patches fix https://bugzilla.redhat.com/show_bug.cgi?id=1401241 The sssd.conf used in order to reproduce this issue looks like: ``` [sssd] config_file_version = 2 services = nss, pam domains = ad.fidencio.lan [nss] [pam] [domain/ad.fidencio.lan] ad_domain = ad.fidencio.lan krb5_realm = AD.FIDENCIO.LAN realmd_tags = manages-system joined-with-adcli cache_credentials = True krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d ldap_referrals = false enumerate = false id_provider = ldap #id_provider = ad auth_provider = krb5 chpass_provider = krb5 access_provider = ldap ldap_sasl_mech = GSSAPI ldap_schema = ad ldap_user_object_class = user ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true ``` The reproducer can be found in the bug report. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/128/head:pr128 git checkout pr128

5 90

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

21 Nov '17

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

4 62

[sssd PR#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#136][opened] Tlog integration WIP
by fidencio 27 Jul '17

27 Jul '17

URL: https://github.com/SSSD/sssd/pull/136 Author: spbnick Title: #136: Tlog integration WIP Action: opened PR body: """ @lslebodn, @pbrezina, this is the work-in-progress tlog integration patchset I'd like to work on with you. This is not for merging as it is. We can go over it when we meet :) """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/136/head:pr136 git checkout pr136

5 87

[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

WIP design page: Subdomain configuration
by Michal Židek 07 Apr '17

07 Apr '17

Hi, I started working on the design page for subdomain configuration in server mode. It is located here: https://fedorahosted.org/sssd/wiki/DesignDocs/SubdomConf The implementation details and how to debug sections will be added later. For now, the design page is short but should at least set the proper expectations for the feature. Please tell me if you think something is unclear. I will add more to the page soon. Michal

3 5

[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#127][opened] ssh: use cache_req
by fidencio 10 Mar '17

10 Mar '17

URL: https://github.com/SSSD/sssd/pull/127 Author: pbrezina Title: #127: ssh: use cache_req Action: opened PR body: """ This patches makes SSH responder use the cache_req interface. Since this responder uses that same `cache-domain-cache` lookup logic for host certificates I implemented `host by name` request in `cache_req`. In order to achieve this I moved data provider lookup function from `cache_req` code into plugins. The first two patches fixes minor issues in the SSH responder and should be pushed to earlier versions as well. The first patch fix a little issue introduced probably by overrides and the second patch removes name qualification since it is already qualified in the sysdb since fqname patches. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/127/head:pr127 git checkout pr127

4 22

[sssd PR#141][opened] PAM: Use cache_req_user_by_name_*()
by fidencio 03 Mar '17

03 Mar '17

URL: https://github.com/SSSD/sssd/pull/141 Author: fidencio Title: #141: PAM: Use cache_req_user_by_name_*() Action: opened PR body: """ PAM responder has been already using a lot from cache_req and one of the missing parts (most likely the only one?) was that pam_check_user_search() has been using sss_dp_get_account_send(), which could be dropped (and a lot of code around it) in favour of using cache_req_user_by_name_*() instead. Resolves: https://fedorahosted.org/sssd/ticket/1126 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/141/head:pr141 git checkout pr141

5 50

[sssd PR#137][opened] Initial pkinit support
by fidencio 23 Feb '17

23 Feb '17

URL: https://github.com/SSSD/sssd/pull/137 Author: sumit-bose Title: #137: Initial pkinit support Action: opened PR body: """ This series of patches add initial support for PKINIT (https://fedorahosted.org/sssd/ticket/3270) by forwarding the information about the selected certificate from the Smartcard to the backends. Currently only the krb5 backend supports Smartcard authentication the other backends will return an error code which will tell the PAM responder to fall back to local Smartcard authentication as it is currently the case. Testing requires a working PKINIT setup which e.g. can be done with AD by setting up a CA and generating certificates as described in https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationTestin…. But currently more important is regression testing, i.e. making sure all other authentication methods are still working as expected. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/137/head:pr137 git checkout pr137

4 24

[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#106][opened] Add a new "files" provider
by fidencio 15 Feb '17

15 Feb '17

URL: https://github.com/SSSD/sssd/pull/106 Author: jhrozek Title: #106: Add a new "files" provider Action: opened PR body: """ This patch set implements a new provider that mirrors the contents of passwd and groups files. The intent is to make these users and groups available through the SSSD memory cache to improve performance and make it possible to read extended attributes via the sssd D-Bus interface. As the next step, we will implement a writable D-Bus interface to make it possible to also manage local users with an API and supersede the AccountService API. At the moment, the domain must be enabled explicitly. When this branch is merged, another commit would also enable the files domain for all installations by default. In order to make the resolution precise, the files domain is disabled once an inotify notification arrives During testing, I realized there might be a delay between changing the UNIX files by replacing them and *receiving* the inotify notification. Therefore the tests add a sleep as well. That's not nice and I would be glad if the reviewer can spot how to speed up the inotify notification receiving. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/106/head:pr106 git checkout pr106

3 42

[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#138][opened] IPA: Skip conflict entries associated with sudo rules
by fidencio 07 Feb '17

07 Feb '17

URL: https://github.com/SSSD/sssd/pull/138 Author: justin-stephenson Title: #138: IPA: Skip conflict entries associated with sudo rules Action: opened PR body: """ SSSD retrieves sudo rule information from the IPA LDAP tree, conflict entries will cause problems for SSSD and disallow sudo access when SSSD code is parsing entries associated with sudo rules. This PR sets a skip_entry boolean when it is appropriate and skips over these conflict entries. Ticket: https://fedorahosted.org/sssd/ticket/3288 Reproducer steps: Create host conflict entry and associate it with a sudo rule that is assigned to certain hosts, attempt to sudo as IDM user. I had some difficulty attempting to force replication issues causing the creation of a conflict entry, the below manual ldapmodify steps will work also: - Retrieve the DN of the sudoRule `# ipa sudorule-find --all --raw | grep 'dn: ' dn: ipaUniqueID=e9025c46-ddab-11e6-9096-525400af7498,cn=sudorules,cn=sudo,dc=jstephen,dc=local` - Run ldapmodify similar to below dn: ipaUniqueID=e9025c46-ddab-11e6-9096-525400af7498,cn=sudorules,cn=sudo,dc=jstephen,dc=local changetype: modify add: memberHost memberHost: fqdn=testhost.jstephen.local+nsuniqueid=cb3d7383-ddb511e6-8c9996c1-71a1e36a,cn=computers,cn=accounts,dc=jstephen,dc=local """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/138/head:pr138 git checkout pr138

4 21

[sssd PR#108][opened] Partially revert "CONFIG: Use default config when none provided"
by fidencio 07 Feb '17

07 Feb '17

URL: https://github.com/SSSD/sssd/pull/108 Author: lslebodn Title: #108: Partially revert "CONFIG: Use default config when none provided" Action: opened PR body: """ This reverts part of commit 59744cff6edb106ae799b2321cb8731edadf409a. Removed is copying of default configuration into /etc/sssd/sssd.conf Sample configurations is still part of installation. Copying default configuration from /usr/lib64/sssd/conf/sssd.conf -> /etc/sssd/sssd.conf is not the best idea. There are better way how to use default configuration and we will need to change anyway due to files provider. I can revert sample configuration as well. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/108/head:pr108 git checkout pr108

3 6

[sssd PR#112][opened] FAILOVER: Improve port status log messages
by fidencio 06 Feb '17

06 Feb '17

URL: https://github.com/SSSD/sssd/pull/112 Author: justin-stephenson Title: #112: FAILOVER: Improve port status log messages Action: opened PR body: """ This PR is created to ensure administrators do not follow the wrong path troubleshooting issues, especially with messages such as: `Port status of port 636 for server 'server' is 'not working'` This patch should help to clarify that there is no direct relationship between port status and actual networking status. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/112/head:pr112 git checkout pr112

2 17

sssd-1.14.3 milestone cleanup
by Jakub Hrozek 02 Feb '17

02 Feb '17

Hi, despite new development happening in the sssd-1-15 branch (aka master), there are still too many tickets in the 1.14.3 milestone. The tickets should be moved out to current milestones unless someone is really working on them. These are: * https://fedorahosted.org/sssd/ticket/3063 - add an integration test for the configuration include directories - would it be enough to have two users in two search bases and drop a snippet with the second base, then try to resolve a user? If yes, this is a one-hour effort, any takers? If not, move to CI milestone - Lukas said there would be issue with integration test would be how to detect whether libini_config suports it (rhel6 does not support it). Therefore I suggest we move the ticket to CI milestone. * https://fedorahosted.org/sssd/ticket/3085 - looks fixed in https://git.fedorahosted.org/cgit/sssd.git/commit/?id=11540d9efb85b9ed0341e… OK to close? - Lukas already added a +1 last week on our meeting, so I'll probably close the ticket. * https://fedorahosted.org/sssd/ticket/3197 - add a line to sssd-ad man page on how does the POSIX attrs in GC work - Someone suggested reverting the logic for POSIX-attrs-in-GC lately, but I forgot the details, does anyone remember? Otherwise this is a 5-minute patch, so I suggest just closing it. * https://fedorahosted.org/sssd/ticket/3208 - Need detailed information about config-check option - what is this ticket about? Do we need it? I suggest we just close it * https://fedorahosted.org/sssd/ticket/3222 - sssd still showing ipa user after removed from last group - unless anyone is actively working on the ticket, just move to patches welcome * https://fedorahosted.org/sssd/ticket/2554 - Update spec file according to updated guidelines - Unless anyone would like to clean up our reference upstream specfile, I suggest we close the ticket * https://fedorahosted.org/sssd/ticket/3113 - Please move sudo_timed option to sssd-sudo man page - 5 minutes patch and George is unlikely to send a patch, any takers? * https://fedorahosted.org/sssd/ticket/3074 - Move timestamp cache to tmpfs * https://fedorahosted.org/sssd/ticket/3097 - Measure the difference between tmpfs database and NOSYNC database - tmpfs provides very little benefit, close with an explanation After this milestone is cleaned up, I'll finally populate the 1.15 Beta milestone..

5 11

[sssd PR#126][opened] ldap_child: Fix use after free
by fidencio 01 Feb '17

01 Feb '17

URL: https://github.com/SSSD/sssd/pull/126 Author: lslebodn Title: #126: ldap_child: Fix use after free Action: opened PR body: """ In case on any krb5 related error, we tried to send string interpretation of krb5 error tb parrent in prepare_response. However, we cannot use global krb5 context (krb5_error_ctx) because the context is every time released in done section of ldap_child_get_tgt_sync. This patch rather return duplicated string to prevent use after free. Backtrace: ``` #0 __strchr_sse42 () at ../sysdeps/x86_64/multiarch/strchr.S:100 100 ../sysdeps/x86_64/multiarch/strchr.S: No such file or directory. Thread 1 (Thread 0x7fc96cad5880 (LWP 11201)): #0 __strchr_sse42 () at ../sysdeps/x86_64/multiarch/strchr.S:100 No locals. #1 0x00007fc96be43725 in err_fmt_fmt (msg=0x7fc96d1cf8d0 "Cannot find KDC for requested realm", code=-1765328230, err_fmt=<optimized out>) at kerrs.c:152 buf = {buftype = K5BUF_DYNAMIC, data = 0x7fc96d1cdb10, space = 128, len = 0} p = <optimized out> s = 0xdededededededede <Address 0xdededededededede out of bounds> #2 krb5_get_error_message (ctx=<optimized out>, code=code@entry=-1765328230) at kerrs.c:184 std = 0x7fc96d1cf8d0 "Cannot find KDC for requested realm" #3 0x00007fc96cb224e5 in sss_krb5_get_error_message (ctx=<optimized out>, ec=ec@entry=-1765328230) at src/util/sss_krb5.c:424 No locals. #4 0x00007fc96cb1fbb0 in prepare_response (rsp=<synthetic pointer>, kerr=-1765328230, expire_time=0, ccname=0x0, mem_ctx=0x7fc96d1cb390) at src/providers/ldap/ldap_child.c:553 ret = <optimized out> r = 0x7fc96d1cd8b0 krb5_msg = 0x0 ``` Related parts of logs: ``` [System Logs]: Jan 17 06:20:08 fserver-1658118.example.com [sssd[ldap_child[15788]]][15788]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'FSERVER-1658118$(a)EXAMPLE.COM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection. Jan 17 06:20:08 fserver-1658118.example.com [sssd[ldap_child[15788]]][15788]: Client 'FSERVER-1658118$(a)EXAMPLE.COM' not found in Kerberos database Jan 17 06:20:08 fserver-1658118.example.com kernel: traps: ldap_child[15788] general protection ip:7f7faf2e505a sp:7ffd3f768478 error:0 in libc-2.17.so[7f7faf260000+1b6000] Jan 17 06:20:08 fserver-1658118.example.com abrt-hook-ccpp[15793]: Process 15788 (ldap_child) of user 0 killed by SIGSEGV - dumping core [User Logs]: Jan 17 06:20:08 fserver-1658118.example.com [sssd[ldap_child[15788]]][15788]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'FSERVER-1658118$(a)EXAMPLE.COM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection. Jan 17 06:20:08 fserver-1658118.example.com [sssd[ldap_child[15788]]][15788]: Client 'FSERVER-1658118$(a)EXAMPLE.COM' not found in Kerberos database Jan 17 06:20:08 fserver-1658118.example.com abrt-hook-ccpp[15793]: Process 15788 (ldap_child) of user 0 killed by SIGSEGV - dumping core ``` """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/126/head:pr126 git checkout pr126

1 5

[sssd PR#133][opened] sbus: use sss_ptr_hash for hash tables
by fidencio 01 Feb '17

01 Feb '17

URL: https://github.com/SSSD/sssd/pull/133 Author: pbrezina Title: #133: sbus: use sss_ptr_hash for hash tables Action: opened PR body: """ This patch reuses `sss_ptr_hash` module introduced in NSS patches in `sbus` code. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/133/head:pr133 git checkout pr133

1 13

[sssd PR#140][opened] gcc7 related fixes
by fidencio 01 Feb '17

01 Feb '17

URL: https://github.com/SSSD/sssd/pull/140 Author: lslebodn Title: #140: gcc7 related fixes Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/140/head:pr140 git checkout pr140

1 14

Identification with openLDAP and authorization with MIT KDC
by Michaël Van de Borne 31 Jan '17

31 Jan '17

Hello list, I know this is a devel list, but I didn't find a user list. Here's my situation: I'm installing Hadoop for a customer, and the Hadoop cluster is secured with Kerberos. I used FreeIPA as a KDC. The customer uses openLDAP as a directory server. Fo now, our solution is to copy the whole openLDAP user base to FreeIPA, and then use FreeIPA for the identification and authorization (all the keytab stuff). But keeping openLDAP and FreeIPA in sync is a nightmare, and I was wondering something: Would it be possible to configure SSSD to simultaneously target the openLDAP server to identify a user, and the FreeIPA server to get the tickets? That way, we can avoid having to keep openLDAP and FreeIPA in sync... All ideas are welcome!! Thank you guys, Cheers, m.

3 3

[RFC] Discussion about enabling socket-activate services to refresh configuration
by Fabiano Fidêncio 31 Jan '17

31 Jan '17

Last Thursday we had a face to face discussion about how socket-activate services could refresh the confdb before starting. There were five of us attending the discussion (Pavel Březina, Lukáš Slebodnik, Simo Sorce, Stephen Gallagher and myself) and the main focus of the discussion was on what to do in a near-future scenario where the monitor won't be present anymore. So, keeping in mind the "no monitor" scenario what has been suggested by Simo is: - Have some sort of inotify in the confdb that, when updated, will trigger the restart of the services. It's really important to note that we want a way to be notified that the file was changed as a whole and not trigger several restarts for each small change possible done in the file; - There were some ideas suggested about adding a timestamp to the confdb or a hash of the file (?) in order to keep track of the latest changes; - As we will restart the services when notified that the confdb changes, we have to be more robust when shutting down any service: as far as I understand/remember it means we must answer the requests already done while not accepting any new request. It applies pretty much to any running service at the moment the confdb becomes updated; - sssd --genconf may be one way to regenerate the confdb and could be used as ExecPreStart in the SSSD unit. For the scneario where the monitor is still around Simo suggested to: - sssd --genconf may be one way to regenerate the confdb (but in the end we won't do that) - SSSD will log that the admin must restart SSSD service in order to have the confdb updated. I'm really not sure about the technical details of this discussion as I didn't have time enough to dig into any of the topics I mentioned in the email. For those who also where in the meeting, please, politely provide some feedback on what I've missed, on what you'd like to expand and so on. Best Regards, -- Fabiano Fidêncio

3 2

Announcing SSSD 1.15.0
by Jakub Hrozek 30 Jan '17

30 Jan '17

== SSSD 1.15.0 === The SSSD team is proud to announce the release of version 1.15.0 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 == * SSSD now allows the responders to be activated by the systemd service manager and exit when idle. This means the services line in sssd.conf is optional and the responders can be started on-demand, simplifying the sssd configuration. Please note that this change is backwards-compatible and the responders listed explicitly in sssd.conf's services line are managed by sssd in the same manner as in previous releases. Please refer to man sssd.conf(5) for more information * The sudo provider is no longer disabled for configurations that do not explicitly include the sudo responder in the services list. In order to disable the sudo-related back end code that executes the periodic LDAP queries, set the sudo_provider to none explicitly * The watchdog signal handler no longer uses signal-unsafe functions. This bug was causing a deadlock in case the watchdog was about to kill a stuck process * A bug that prevented TLS to be set up correctly on systems where libldap links with GnuTLS was fixed * The functionality to alter SSSD configuration through the D-Bus interface provided by the IFP responder was removed. This functionality was not used to the best of our knowledge, had no tests and prevented the InfoPipe responder from running as a non-privileged user. * A bug that prevented statically-linked applications from using libnss_sss was fixed by removing dependency on -lpthreads from the libnss_sss library (please see https://sourceware.org/bugzilla/show_bug.cgi?id=20500 for an example on why linking with -lpthread from an NSS modules is problematic) * Previously, SSSD did not ignore GPOs that were missing the gPCFunctionalityVersion attribute and failed the whole GPO processing. Starting with this version, the GPOs without the gPCFunctionalityVersion are skipped. == Packaging Changes == * The Augeas development libraries are no longer required since the configuration manipulation interface was dropped from the InfoPipe responder * The libsss_config.so internal library was removed as well due to removal of the InfoPipe config management * In order to manage socket-activated or bus activated responders, each responder is now represented by a systemd service file (e.g. sssd-nss.service). All responders except InfoPipe, which is bus-activated, are also managed by a socket unit file (e.g. sssd-nss.socket) == Documentation Changes == * The sssd-secrets responder gained a new option max_payload_size that allows the administrator to limit the maximum size of a secret * A new option responder_idle_timeout was added to support idle termination of socket-activated responders * The sssd-ad and sssd-ipa man pages now summarize differences between the generic Kerberos/LDAP back end and the specialized IPA/AD back ends == Tickets Fixed == https://fedorahosted.org/sssd/ticket/697 Use command line arguments instead env vars for krb5_child https://fedorahosted.org/sssd/ticket/2201 Man pages do not specify that sssd dyndns_refresh_interval < 60 is pulled to 60 seconds https://fedorahosted.org/sssd/ticket/2243 [RFE] Socket-activate responders https://fedorahosted.org/sssd/ticket/2517 krb5_child: Remove getenv() ran as root https://fedorahosted.org/sssd/ticket/3060 better debugging of timestamp cache modifications https://fedorahosted.org/sssd/ticket/3129 [RFE] socket-activate the IFP responder https://fedorahosted.org/sssd/ticket/3151 cache_req: complete the needs of NSS responders https://fedorahosted.org/sssd/ticket/3156 nss_sss might leak memory when calling thread goes away https://fedorahosted.org/sssd/ticket/3214 Update man pages for any AD provider config options that differ from ldap/krb5 providers defaults https://fedorahosted.org/sssd/ticket/3215 Review and update SSSD's wiki pages for 1.15 Alpha release https://fedorahosted.org/sssd/ticket/3235 SSSCTL should not be case sensitive when searching for usernames or groups in a case-insensitive domain https://fedorahosted.org/sssd/ticket/3245 [RFE] Shutdown timeout for {socket,bus}-activated responders https://fedorahosted.org/sssd/ticket/3275 Unchecked return value of sss_cmd_empty_packet(pctx->creq->out); https://fedorahosted.org/sssd/ticket/3283 getsidbyid can fail in some cases due to cache_req refactoring https://fedorahosted.org/sssd/ticket/3284 getsidbyname does not work properly with case insensitive domains == Detailed Changelog == Amith Kumar (1): * MAN: Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds Carl Henrik Lunde (1): * Prevent use after free in fd_input_available David Michael (1): * BUILD: Find a host-prefixed krb5-config when cross-compiling Fabiano Fidêncio (34): * SECRETS: Fix secrets rule in the allowed sections * SECRETS: Add allowed_sec_users_options * SECRETS: Delete all secrets stored during "max_secrets" test * SECRETS: Add configurable payload size limit of a secret * BUILD: Drop libsss_config * IFP: Remove "ChangeDebugTemporarily?" method * AUTOFS: Check return of sss_cmd_empty_packet() * SUDO: Drop logic to disable the backend in case the provider is not set * MONITOR: Expose the monitor's services type * MONITOR: Pass the service type to the RegisterService? method * UTIL: Introduce --socket-activated cmdline option for responders * UTIL: Introduce --dbus-activated cmd option for responders * RESPONDER: Make responders' common code ready for socket activation * AUTOFS: Make AutoFS responder socket-activatable * NSS: Make NSS responder socket-activatable * PAC: Make PAC responder socket-activatable * PAM: Make PAM responder socket-activatable * SSH: Make SSH responder socket-activatable * SUDO: Make Sudo responder socket-activatable * IFP: Make IFP responder dbus-activatable * MONITOR: Split up check_services() * MONITOR: Deal with no services set up * MONITOR: Deal with socket-activated responders * MAN: Mention that the services' list is optional * MAN: "user" doesn't work with socket-activated services * MONITOR: Don't expose monitor_common_send_id() * SBUS: Add a time_t pointer to the sbus_connection * SBUS: Add destructor data to sbus_connection * RESPONDER: Make clear {reset_,}idle_timer() are related to client * RESPONDER: Don't expose client_idle_handler() * RESPONDER: Shutdown {dbus,socket}-activated responders in case they're idle * RESPONDER: Change how client timeout is calculated * SERVER: Set the process group during server_setup() * WATCHDOG: Avoid non async-signal-safe from the signal_handler Howard Guo (1): * sss_client: Defer thread cancellation until completion of nss/pam operations Jakub Hrozek (16): * Updating the version for the 1.14.3 development * Updating the version to track sssd-1-15 development * SYSDB: Split sysdb_try_to_find_expected_dn() into smaller functions * SYSDB: Augment sysdb_try_to_find_expected_dn to match search base as well * MONITOR: Do not set up watchdog for monitor * MONITOR: Remove deprecated pong sbus method * MONITOR: Remove unused shutDown sbus method * Qualify ghost user attribute in case ldap_group_nesting_level is set to 0 * tests: Add a test for group resolution with ldap_group_nesting_level=0 * BUILD: Fix a typo in inotify.m4 * SSH: Use default_domain_suffix for users' authorized keys * SYSDB: Suppress sysdb_delete_ts_entry failed: 0 * STAP: Only print transaction statistics if the script caught some transactions * test_sssctl: Add an integration test for sssctl netgroup-show * KRB5: Advise the user to inspect the krb5_child.log if the child fails with a System Error * IFP: Fix GetUserAttr? Justin Stephenson (2): * MAN: Document different defaults for AD provider * MAN: Document different defaults for IPA provider Lukas Slebodnik (45): * crypto: Port libcrypto code to openssl-1.1 * BUILD: Fix build without samba * libcrypto: Check right value of CRYPTO_memcmp * crypto-tests: Add unit test for sss_encrypt + sss_decrypt * crypto-tests: Rename encrypt decrypt test case * BUILD: Accept krb5 1.15 for building the PAC plugin * dlopen-test: Use portable macro for location of .libs * dlopen-test: Add missing libraries to the check list * dlopen-test: Move libraries to the right "sections" * dlopen-test: Add check for untested libraries * BUILD: Fix linking with librt * KRB5: Remove spurious warning in logs * TESTS: Check new line at end of file * UTIL: Fix implicit declaration of function 'htobe32' * SYSDB: Remove unused prototype from header file * sssctl: Fix missing declaration * UTIL: Fix compilation of sss_utf8 with libunistring * CONFDB: Supress clang false passitive warnings * SIFP: Fix warning format-security * RESPONDER: Remove dead assignment to the variable ret * Fix compilation with python3.6 * intg: Generate tmp dir with lowercase * LDAP: Fix debug messages after errors in *_get_send * LDAP: Removed unused attr_type from users_get_send * LDAP: Remove unused parameter attr_type from groups_get_send * DP: Remove unused constants BE_ATTR_* * DP: Remove unused attr_type from struct dp_id_data * LDAP: Remove attrs_type related TODO comments * sssd_ldb.py: Remove a leftover debug message * intg: Fix python2,3 urllib * intg: Avoid using xrange in tests * intg: Avoid using iteritems for dictionary * intg: Use bytes with hash function * intg: Fix creating of slapd configuration * intg: Use bytes for value of attributes in ldif * intg: Use bytes as input in ctypes * intg: Return strings from ctypes wrappers * intg: Convert output of executed commands to strings * intg: Return list for enumeration functions * SYSDB: Update filter for get object by id * sysdb-tests: Add test for sysdb_search_object_by_id * sysdb: Search also aliases in sysdb_search_object_by_name * sysdb-tests: Add test for sysdb_search_object_by_name * MONITOR: Fix warning with undefined macro HAVE_SYSTEMD * UTIL: Unset O_NONBLOCK for ldap connection Michal Židek (7): * sssctl: Flags for command initialization * ipa: Nested netgroups do not work * common: Fix domain case sensitivity init * sssctl: Search by alias * sssctl: Case insensitive filters * tests: sssctl user/group-show basic tests * MAN: sssctl debug level Mike Ely (1): * ad_access_filter search for nested groups Pavel Březina (40): * cache_req: move from switch to plugins; add logic * cache_req: move from switch to plugins, add plugins * cache_req: switch to new code * cache_req: delete old code * sudo: do not store usn if no rules are found * nss: move nss_ctx->global_names to rctx * ifp: remove unused fields from state * setent_notify: remove unused private context * sss_crypto.h: include required headers * sss_output_name: do not require fq name * cache_req: fix initgroups by name * cache_req: skip first search on bypass cache * cache_req: encapsulate output data into structure * cache_req: add ability to gather result from all domains * cache_req: add ability to filter domains by enumeration * cache_req: add user enumeration * cache_req: add group enumeration * cache_req: add support for service by name * cache_req: add support for service by port * cache_req: add support for services enumeration * cache_req: add support for netgroups * cache_req: allow shallow copy of result * cache_req: allow to return well known object as result * cache_req: return well known objects in object by sid * cache_req: make sure that we always fetch default attrs * cache_req: allow upn search with attrs * cache_req: add object by name * cache_req: add object by id * cache_req: make plug-ins definition const * cache_req: improve debugging * cache_req: fix plugin function description * cache_req: allow to search subdomains without fqn * cache_req: do not set ncache if dp request fails * responders: unify usage of sss_cmd_send_empty and _error * responders: remove checks that are handled inside cache_req * responders: do not try to contact DP with LOCAL provider * utils: add sss_ptr_hash module * nss: rewrite nss responder so it uses cache_req * nss: make nss responder tests work with new code * nss: remove the old code Petr Cech (2): * SYSDB: Adding message to inform which cache is used * SYSDB: Adding message about reason why cache changed Petr Čech (5): * SYSDB: Adding lowercase sudoUser form * TESTS: Extending sysdb sudo store tests * RESPONDER: Adding of return value checking * UTIL: Removing of never read value * SYSDB: Fixing of sudorule without a sudoUser Sorah Fukumori (1): * BUILD: Fix installation without samba Sumit Bose (11): * sysdb: add parent_dom to sysdb_get_direct_parents() * sdap: make some nested group related calls public * LDAP/AD: resolve domain local groups for remote users * PAM: add a test for filter_responses() * PAM: add pam_response_filter option * IPA/AD: check auth ctx before using it * krb5: Use command line arguments instead env vars for krb5_child * krb5: fix two memory leaks * krb5: add tests for common functions * sss_ptr_hash_delete_all: use unsigned long int * libwbclient-sssd: wbcLookupSid() allow NULL arguments Victor Tapia (1): * MONITOR: Create pidfile after responders started

2 1

[sssd PR#135][opened] BUILD: Fix linking of test_wbc_calls
by fidencio 26 Jan '17

26 Jan '17

URL: https://github.com/SSSD/sssd/pull/135 Author: lslebodn Title: #135: BUILD: Fix linking of test_wbc_calls Action: opened PR body: """ Client code does not anymore depend on libpthread in master. This is a reason why we didn't notice any linking failure in master. But the test should be inked with CLIENT_LIBS. ``` CCLD test_wbc_calls /usr/bin/ld: src/sss_client/test_wbc_calls-common.o: undefined reference to symbol 'pthread_mutexattr_setrobust@@GLIBC_2.12' //lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Makefile:12460: recipe for target 'test_wbc_calls' failed ``` """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/135/head:pr135 git checkout pr135

1 10

[sssd PR#120][opened] GPO: Skip GPOs without gPCFunctionalityVersion
by fidencio 25 Jan '17

25 Jan '17

URL: https://github.com/SSSD/sssd/pull/120 Author: mzidek-rh Title: #120: GPO: Skip GPOs without gPCFunctionalityVersion Action: opened PR body: """ We falsely stopped GPO processing when Group Policy Container in AD did not contain gPCFunctionalityVersion. Such GPOs should be ignored by SSSD. Resolves: https://fedorahosted.org/sssd/ticket/3269 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/120/head:pr120 git checkout pr120

1 15

[sssd PR#134][opened] dp_request_table: remove unused #includes
by fidencio 25 Jan '17

25 Jan '17

URL: https://github.com/SSSD/sssd/pull/134 Author: pbrezina Title: #134: dp_request_table: remove unused #includes Action: opened PR body: """ Trivial patch attached. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/134/head:pr134 git checkout pr134

1 4

[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#107][opened] WATCHDOG: Avoid non async-signal-safe from the signal_handler
by fidencio 25 Jan '17

25 Jan '17

URL: https://github.com/SSSD/sssd/pull/107 Author: fidencio Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler Action: opened PR body: """ While debugging rhbz#1396912 some deadlock on sssd_be was noticed[0] and it's been caused by the use of non async-signal-safe functions from the signal_handler (please, see man 7 signal for more info about which are the async-signal-safe functions that can be used). The removal of those functions we lose some debug messages, which is the least of problems now. Also instead of re-setting the watchdog timeout in case of time-shift (please, see b8ceaeb for more info), let's just re-set the timer's time. Along with this commit, the function to teardown the watchdog has been removed as it's not used anymore. [0]: [root@dusan ~]# pstack 17922 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007fe707d04f93 in _L_lock_14932 () from /lib64/libc.so.6 #2 0x00007fe707d02013 in __GI___libc_malloc (bytes=140630248638304, bytes@entry=15) at malloc.c:2891 #3 0x00007fe707d0888a in __GI___strdup (s=0x7fe707dff4f7 "/etc/localtime") at strdup.c:42 #4 0x00007fe707d31b61 in tzset_internal (always=<optimized out>, explicit=explicit@entry=1) at tzset.c:438 #5 0x00007fe707d32523 in __tz_convert (timer=timer@entry=0x7ffcd5d2b090, use_localtime=use_localtime@entry=1, tp=tp@entry=0x7fe708041d40 <_tmbuf>) at tzset.c:621 #6 0x00007fe707d30521 in __GI_localtime (t=t@entry=0x7ffcd5d2b090) at localtime.c:42 #7 0x00007fe70886c7b0 in sss_vdebug_fn (file=<optimized out>, line=<optimized out>, function=0x7fe70bff27f0 <__FUNCTION__.9379> "watchdog_handler", level=16, flags=flags@entry=0, format=format@entry=0x7fe70bff2760 "Watchdog timer overflow, killing process!\n", ap=ap@entry=0x7ffcd5d2b130) at src/util/debug.c:248 #8 0x00007fe70886c995 in sss_debug_fn (file=file@entry=0x7fe70bff263b "src/util/util_watchdog.c", line=line@entry=82, function=function@entry=0x7fe70bff27f0 <__FUNCTION__.9379> "watchdog_handler", level=level@entry=16, format=format@entry=0x7fe70bff2760 "Watchdog timer overflow, killing process!\n") at src/util/debug.c:284 #9 0x00007fe70bfdb409 in watchdog_handler (sig=<optimized out>) at src/util/util_watchdog.c:81 #10 <signal handler called> #11 0x00007fe707cff664 in _int_malloc (av=av@entry=0x7fe70803c760 <main_arena>, bytes=bytes@entry=151) at malloc.c:3494 #12 0x00007fe707d01fbc in __GI___libc_malloc (bytes=bytes@entry=151) at malloc.c:2893 #13 0x00007fe708450749 in __talloc_with_prefix (prefix_len=0, size=55, context=0x7fe718373210) at ../talloc.c:668 #14 __talloc (size=55, context=0x7fe718373210) at ../talloc.c:708 #15 _talloc_named_const (name=0x7fe70bb7015d "../common/ldb_pack.c:425", size=55, context=0x7fe718373210) at ../talloc.c:865 #16 talloc_named_const (context=<optimized out>, size=size@entry=55, name=name@entry=0x7fe70bb7015d "../common/ldb_pack.c:425") at ../talloc.c:1606 #17 0x00007fe70bb61803 in ldb_unpack_data_only_attr_list (ldb=ldb@entry=0x7fe70e4d52c0, data=data@entry=0x7ffcd5d2b990, message=0x7fe7184aa1e0, list=list@entry=0x0, list_size=list_size@entry=0, nb_elements_in_db=nb_elements_in_db@entry=0x0) at ../common/ldb_pack.c:425 #18 0x00007fe70bb61a7d in ldb_unpack_data (ldb=ldb@entry=0x7fe70e4d52c0, data=data@entry=0x7ffcd5d2b990, message=<optimized out>) at ../common/ldb_pack.c:470 #19 0x00007fe6fdc29b46 in ltdb_parse_data_unpack (key=..., data=..., private_data=0x7ffcd5d2ba70) at ../ldb_tdb/ldb_search.c:249 #20 0x00007fe70a5e0a24 in tdb_parse_data (tdb=tdb@entry=0x7fe70e4eaa10, key=..., offset=15619748, len=414772, parser=parser@entry=0x7fe6fdc29b10 <ltdb_parse_data_unpack>, private_data=private_data@entry=0x7ffcd5d2ba70) at ../common/io.c:637 #21 0x00007fe70a5dc1fc in tdb_parse_record (tdb=0x7fe70e4eaa10, key=..., parser=parser@entry=0x7fe6fdc29b10 <ltdb_parse_data_unpack>, private_data=private_data@entry=0x7ffcd5d2ba70) at ../common/tdb.c:253 #22 0x00007fe6fdc29e7b in ltdb_search_dn1 (module=module@entry=0x7fe70e4eab50, dn=dn@entry=0x7fe7183c4940, msg=msg@entry=0x7fe7184aa1e0) at ../ldb_tdb/ldb_search.c:287 #23 0x00007fe6fdc2acbb in ltdb_dn_list_load (module=module@entry=0x7fe70e4eab50, dn=dn@entry=0x7fe7183c4940, list=list@entry=0x7fe7183c3a30) at ../ldb_tdb/ldb_index.c:181 #24 0x00007fe6fdc2bbbb in ltdb_index_add1 (module=module@entry=0x7fe70e4eab50, dn=dn@entry=0x7fe7183bf3e0 "name=testuser7045(a)domain.com,cn=users,cn=DOMAIN.COM,cn=sysdb", v_idx=v_idx@entry=0, el=<optimized out>, el=<optimized out>) at ../ldb_tdb/ldb_index.c:1134 #25 0x00007fe6fdc2c62c in ltdb_index_add_el (el=0x7fe7184aa3e0, dn=0x7fe7183bf3e0 "name=testuser7045(a)domain.com,cn=users,cn=DOMAIN.COM,cn=sysdb", module=0x7fe70e4eab50) at ../ldb_tdb/ldb_index.c:1180 #26 ltdb_index_add_element (module=module@entry=0x7fe70e4eab50, dn=<optimized out>, el=el@entry=0x7fe7184aa3e0) at ../ldb_tdb/ldb_index.c:1290 #27 0x00007fe6fdc290bb in ltdb_modify_internal (module=module@entry=0x7fe70e4eab50, msg=0x7fe7183bf0c0, req=req@entry=0x7fe7183bdc10) at ../ldb_tdb/ldb_tdb.c:903 #28 0x00007fe6fdc2958a in ltdb_modify (ctx=0x7fe7183c2950, ctx=0x7fe7183c2950) at ../ldb_tdb/ldb_tdb.c:998 #29 ltdb_callback (ev=<optimized out>, te=<optimized out>, t=..., private_data=<optimized out>) at ../ldb_tdb/ldb_tdb.c:1380 #30 0x00007fe708664b4f in tevent_common_loop_timer_delay (ev=ev@entry=0x7fe70e4d2890) at ../tevent_timed.c:341 #31 0x00007fe708665b5a in epoll_event_loop_once (ev=0x7fe70e4d2890, location=<optimized out>) at ../tevent_epoll.c:911 #32 0x00007fe708664257 in std_event_loop_once (ev=0x7fe70e4d2890, location=0x7fe70bb72ec5 "../common/ldb.c:631") at ../tevent_standard.c:114 #33 0x00007fe70866040d in _tevent_loop_once (ev=ev@entry=0x7fe70e4d2890, location=location@entry=0x7fe70bb72ec5 "../common/ldb.c:631") at ../tevent.c:533 #34 0x00007fe70bb6bc4f in ldb_wait (handle=0x7fe7183c4530, type=<optimized out>) at ../common/ldb.c:631 #35 0x00007fe70bb6c793 in ldb_autotransaction_request (ldb=0x7fe70e4d52c0, req=0x7fe7183bdc10) at ../common/ldb.c:573 #36 0x00007fe70bb6d263 in ldb_modify (ldb=ldb@entry=0x7fe70e4d52c0, message=<optimized out>) at ../common/ldb.c:1655 #37 0x00007fe70bfa2ab5 in sysdb_set_cache_entry_attr (ldb=0x7fe70e4d52c0, entry_dn=entry_dn@entry=0x7fe7183c4760, attrs=attrs@entry=0x7fe7183bf680, mod_op=mod_op@entry=2) at src/db/sysdb_ops.c:1159 #38 0x00007fe70bfa304d in sysdb_rep_ts_entry_attr (sysdb=0x7fe70e4eadd0, attrs=0x7fe7183bf680, entry_dn=0x7fe7183c4760) at src/db/sysdb_ops.c:1218 #39 sysdb_set_ts_entry_attr (sysdb=sysdb@entry=0x7fe70e4eadd0, entry_dn=entry_dn@entry=0x7fe7183c4760, attrs=attrs@entry=0x7fe7183bb840, mod_op=mod_op@entry=2) at src/db/sysdb_ops.c:1248 #40 0x00007fe70bfa4aa9 in sysdb_set_entry_attr (sysdb=0x7fe70e4eadd0, entry_dn=0x7fe7183c4760, attrs=attrs@entry=0x7fe7183bb840, mod_op=mod_op@entry=2) at src/db/sysdb_ops.c:1199 #41 0x00007fe70bfa4b5f in sysdb_set_user_attr (domain=domain@entry=0x7fe70e4d62f0, name=name@entry=0x7fe7183c01f0 "testuser7045(a)domain.com", attrs=attrs@entry=0x7fe7183bb840, mod_op=mod_op@entry=2) at src/db/sysdb_ops.c:1285 #42 0x00007fe70bfa58c3 in sysdb_add_user (domain=domain@entry=0x7fe70e4d62f0, name=name@entry=0x7fe7183c01f0 "testuser7045(a)domain.com", uid=uid@entry=1415408147, gid=<optimized out>, gid@entry=1415400513, gecos=gecos@entry=0x7fe710465d00 "Test User7045", homedir=homedir@entry=0x0, shell=shell@entry=0x0, orig_dn=orig_dn@entry=0x7fe710465940 "CN=Test User7045,OU=Sales,DC=DOMAIN,DC=COM", attrs=attrs@entry=0x7fe7183bb840, cache_timeout=cache_timeout@entry=5400, now=now@entry=1481105315) at src/db/sysdb_ops.c:1928 #43 0x00007fe70bfab271 in sysdb_store_new_user (now=1481105315, cache_timeout=5400, attrs=0x7fe7183bb840, orig_dn=0x7fe710465940 "CN=Test User7045,OU=Sales,DC=DOMAIN,DC=COM", shell=0x0, homedir=0x0, gecos=0x7fe710465d00 "Test User7045", gid=1415400513, uid=1415408147, name=0x7fe7183c01f0 "testuser7045(a)domain.com", domain=0x7fe70e4d62f0) at src/db/sysdb_ops.c:2549 #44 sysdb_store_user (domain=domain@entry=0x7fe70e4d62f0, name=0x7fe7183c01f0 "testuser7045(a)domain.com", pwd=pwd@entry=0x0, uid=1415408147, gid=1415400513, gecos=gecos@entry=0x7fe710465d00 "Test User7045", homedir=homedir@entry=0x0, shell=shell@entry=0x0, orig_dn=orig_dn@entry=0x7fe710465940 "CN=Test User7045,OU=Sales,DC=DOMAIN,DC=COM", attrs=attrs@entry=0x7fe7183bb840, remove_attrs=0x7fe7183c08a0, cache_timeout=cache_timeout@entry=5400, now=now@entry=1481105315) at src/db/sysdb_ops.c:2499 #45 0x00007fe6fba0d9f9 in sdap_save_user (memctx=memctx@entry=0x7fe70e544ee0, opts=opts@entry=0x7fe70e518400, dom=dom@entry=0x7fe70e4d62f0, attrs=<optimized out>, _usn_value=_usn_value@entry=0x7ffcd5d2c260, now=now@entry=1481105315) at src/providers/ldap/sdap_async_users.c:509 #46 0x00007fe6fba0df9a in sdap_save_users (memctx=memctx@entry=0x7fe70e544e40, sysdb=0x7fe70e4eadd0, dom=0x7fe70e4d62f0, opts=0x7fe70e518400, users=<optimized out>, num_users=10006, _usn_value=_usn_value@entry=0x7fe70e544e60) at src/providers/ldap/sdap_async_users.c:572 #47 0x00007fe6fba0e460 in sdap_get_users_done (subreq=<optimized out>) at src/providers/ldap/sdap_async_users.c:938 #48 0x00007fe6fba0c9d5 in sdap_search_user_process (subreq=0x0) at src/providers/ldap/sdap_async_users.c:814 #49 0x00007fe6fba07379 in generic_ext_search_handler (subreq=0x0, opts=<optimized out>) at src/providers/ldap/sdap_async.c:1689 #50 0x00007fe6fba0991b in sdap_get_generic_op_finished (op=<optimized out>, reply=<optimized out>, error=<optimized out>, pvt=<optimized out>) at src/providers/ldap/sdap_async.c:1621 #51 0x00007fe6fba083cd in sdap_process_message (ev=<optimized out>, sh=<optimized out>, msg=0x7fe70e5f9ce0) at src/providers/ldap/sdap_async.c:353 #52 sdap_process_result (ev=<optimized out>, pvt=<optimized out>) at src/providers/ldap/sdap_async.c:197 #53 0x00007fe708664b4f in tevent_common_loop_timer_delay (ev=ev@entry=0x7fe70e4cbc30) at ../tevent_timed.c:341 #54 0x00007fe708665b5a in epoll_event_loop_once (ev=0x7fe70e4cbc30, location=<optimized out>) at ../tevent_epoll.c:911 #55 0x00007fe708664257 in std_event_loop_once (ev=0x7fe70e4cbc30, location=0x7fe70bfee8e7 "src/util/server.c:702") at ../tevent_standard.c:114 #56 0x00007fe70866040d in _tevent_loop_once (ev=ev@entry=0x7fe70e4cbc30, location=location@entry=0x7fe70bfee8e7 "src/util/server.c:702") at ../tevent.c:533 #57 0x00007fe7086605ab in tevent_common_loop_wait (ev=0x7fe70e4cbc30, location=0x7fe70bfee8e7 "src/util/server.c:702") at ../tevent.c:637 #58 0x00007fe7086641f7 in std_event_loop_wait (ev=0x7fe70e4cbc30, location=0x7fe70bfee8e7 "src/util/server.c:702") at ../tevent_standard.c:140 #59 0x00007fe70bfd1993 in server_loop (main_ctx=0x7fe70e4cd080) at src/util/server.c:702 #60 0x00007fe70c84cb82 in main (argc=8, argv=<optimized out>) at src/providers/data_provider_be.c:587 Resolves: https://fedorahosted.org/sssd/ticket/3266 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/107/head:pr107 git checkout pr107

2 71

RFC: 1.15.0 release notes
by Jakub Hrozek 25 Jan '17

25 Jan '17

Hi, It would be beneficial to release an upstream tarball in order to get the latest upstream code to Debian testing. I wrote up the release notes page: https://fedorahosted.org/sssd/wiki/Releases/Notes-1.15.0 and unless there is no push-back, I will tag and release the tarball tomorrow (Wed Jan 25).

2 2

[sssd PR#131][opened] MONITOR: Fix warning with undefined macro HAVE_SYSTEMD
by fidencio 24 Jan '17

24 Jan '17

URL: https://github.com/SSSD/sssd/pull/131 Author: lslebodn Title: #131: MONITOR: Fix warning with undefined macro HAVE_SYSTEMD Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/131/head:pr131 git checkout pr131

1 6

[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

[sssd PR#130][opened] Fix for 3284
by fidencio 23 Jan '17

23 Jan '17

URL: https://github.com/SSSD/sssd/pull/130 Author: lslebodn Title: #130: Fix for 3284 Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/130/head:pr130 git checkout pr130

1 4

[sssd PR#129][opened] Fix for 3283
by fidencio 23 Jan '17

23 Jan '17

URL: https://github.com/SSSD/sssd/pull/129 Author: lslebodn Title: #129: Fix for 3283 Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/129/head:pr129 git checkout pr129

1 7

[sssd PR#115][opened] libwbclient-sssd: wbcLookupSid() allow NULL arguments
by fidencio 21 Jan '17

21 Jan '17

URL: https://github.com/SSSD/sssd/pull/115 Author: sumit-bose Title: #115: libwbclient-sssd: wbcLookupSid() allow NULL arguments Action: opened PR body: """ Some caller might not be interested in some of the values wbcLookupSid() returns and just pass NULL. Currently 'net ads user info' does this because it is not interested in the domain. wbcLookupSid() should handle this gracefully. Resolves https://fedorahosted.org/sssd/ticket/3273 A unit-test for wbcLookupSid() is added as well. I had to wrap sss_nss_getnamebysid() because the test shouldn't connect to SSSD but just return some result. Interestingly the wrapping didn't work when I just added libwbclient.la to _LDADD but I had to explicitly add the needed sources. Does anyone know why? """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/115/head:pr115 git checkout pr115

1 3

[sssd PR#121][opened] AUTOFS: Check return of sss_cmd_empty_packet()
by fidencio 20 Jan '17

20 Jan '17

URL: https://github.com/SSSD/sssd/pull/121 Author: fidencio Title: #121: AUTOFS: Check return of sss_cmd_empty_packet() Action: opened PR body: """ Just to make the static analyzer happier. Resolves: https://fedorahosted.org/sssd/ticket/3275 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/121/head:pr121 git checkout pr121

1 5

$ reconfig && chmake failed
by amit kumar 18 Jan '17

18 Jan '17

PASS: refcount-tests FAIL: fail_over-tests PASS: find_uid-tests PASS: auth-tests PASS: ipa_ldap_opt-tests PASS: ad_ldap_opt-tests PASS: crypto-tests PASS: util-tests PASS: debug-tests PASS: ipa_hbac-tests PASS: sss_idmap-tests PASS: responder_socket_access-tests PASS: sysdb-tests PASS: safe-format-tests PASS: sysdb_ssh-tests PASS: sbus_tests PASS: sbus_codegen_tests PASS: test_fo_srv PASS: resolv-tests ============================================================================ Testsuite summary for sssd 1.14.90 ============================================================================ # TOTAL: 83 # PASS: 82 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See ./test-suite.log Please report to sssd-devel(a)lists.fedorahosted.org ============================================================================ # vim ./test_suite.log ==================================== sssd 1.14.90: ./test-suite.log ==================================== # TOTAL: 83 # PASS: 82 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: fail_over-tests ===================== Running suite(s): fail_over 50%: Checks: 2, Failures: 1, Errors: 0 ../src/tests/fail_over-tests.c:162:F:FAIL_OVER Tests:test_fo_resolve_service:0: ../src/tests/fail_over-tests.c:254: Expected return of 0, got 110 FAIL fail_over-tests (exit status: 1) -- Thanks Amit Kumar There are three ways to get something done: (1) Do it yourself. (2) Hire someone to do it for you. (3) Forbid your kids to do it.

3 2

[sssd PR#122][opened] Port integration tests to python3
by fidencio 16 Jan '17

16 Jan '17

URL: https://github.com/SSSD/sssd/pull/122 Author: lslebodn Title: #122: Port integration tests to python3 Action: opened PR body: """ Attached patches fixed python 2/3 compatibility of integration tests. You will need to install following packages in fedora: python3-ldb, python3-pyldap, python3-requests And for testing purposes you can use ``` make intgcheck-run PYTHON2=/usr/bin/python2 make intgcheck-run PYTHON2=/usr/bin/python3 ``` I will need to figure out how to incorporate it into CI script. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/122/head:pr122 git checkout pr122

1 4

[sssd PR#125][opened] RESPONDER: Adding of return value checking
by fidencio 16 Jan '17

16 Jan '17

URL: https://github.com/SSSD/sssd/pull/125 Author: celestian Title: #125: RESPONDER: Adding of return value checking Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/125/head:pr125 git checkout pr125

1 4

[sssd PR#124][opened] Fix a segfault in IFP's GetUserAttr
by fidencio 16 Jan '17

16 Jan '17

URL: https://github.com/SSSD/sssd/pull/124 Author: jhrozek Title: #124: Fix a segfault in IFP's GetUserAttr Action: opened PR body: """ This PR fixes a crash in GetUserAttr. To reproduce, it's enough to: dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:admin array:string:name """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/124/head:pr124 git checkout pr124

1 8

[sssd PR#119][opened] Remove unused Attr type
by fidencio 16 Jan '17

16 Jan '17

URL: https://github.com/SSSD/sssd/pull/119 Author: lslebodn Title: #119: Remove unused Attr type Action: opened PR body: """ I noticed that there is an unused parameter in `users_get_send`. But it went deeper and more code could be removed. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/119/head:pr119 git checkout pr119

1 8

[sssd PR#123][opened] MAN: sssctl debug level
by fidencio 13 Jan '17

13 Jan '17

URL: https://github.com/SSSD/sssd/pull/123 Author: mzidek-rh Title: #123: MAN: sssctl debug level Action: opened PR body: """ Use tools specific reference to debog level explanation in sssctl man page. Resolves: https://fedorahosted.org/sssd/ticket/3085 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/123/head:pr123 git checkout pr123

1 6

[sssd PR#110][opened] Add more DEBUG messages to help admins diagnose Kerberos login failures
by fidencio 12 Jan '17

12 Jan '17

URL: https://github.com/SSSD/sssd/pull/110 Author: jhrozek Title: #110: Add more DEBUG messages to help admins diagnose Kerberos login failures Action: opened PR body: """ This PR contains two trivial (code-wise) patches that just add one DEBUG message each. It's quite common for admins to get stuck diagnosing issues where the krb5_child process exists with system error. Moreover, many system errors are caused by issues during Kerberos ticket validation where the second patch tries to help to give some tips. I hope the first patch should be OK to merge. With the second one, I was struggling a bit to find some useful debug message. If anyone can think about a better one, I'm all ears. Also, if the DEBUG message would be too misleading in the general case, I'm equally fine with dropping the second patch. At least the first one would help to avoid admins asking for help if all we would tell them is to go and look into the krb5_child.log anyway -- so IMO it makes sense to just put that info to a debug message. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/110/head:pr110 git checkout pr110

1 15

Question about tevent request flow in ipa_add_ad_memberships_get_next()
by Justin Stephenson 12 Jan '17

12 Jan '17

Hello all, I was able to reproduce a customer issue with IPA - AD trust external memberships group processing caused by replication conflicts, in this case it is related to a permission that is tied to the IDM trust group through RBAC(sorry, I have not raised a ticket for it just yet). This issue is evident in the logs here: [add_ad_user_to_cached_groups] (0x4000): Group [cn=custompermission+nsuniqueid=92931c98-d84011e6-9a0896c1-71a1e36a,cn=permissions,cn=pbac,dc=jstephen,dc=local] not in the cache. <snip> [ipa_add_ad_memberships_get_next] (0x0040): Invalid group DN [cn=custompermission+nsuniqueid=92931c98-d84011e6-9a0896c1-71a1e36a,cn=permissions,cn=pbac,dc=jstephen,dc=local]. [ipa_add_ad_memberships_done] (0x0040): ipa_add_ad_memberships request failed. It is clear the problem occurs here val = ldb_dn_get_rdn_val(group_dn); if (val == NULL || val->data == NULL) { DEBUG(SSSDBG_OP_FAILURE, "Invalid group DN [%s].\n", state->groups[state->iter]); ret = EINVAL; goto fail; } I was looking at writing a patch which skips this group instead of failing the operation, though perhaps this is not the best method to solve this issue. I see that ipa_add_ad_memberships_get_next() sets a callback to ipa_add_ad_memberships_get_group_done() which then calls ipa_add_ad_memberships_get_next() again for the next group to be processed. I tried the following patch based on this, but it does not work and causes a major failure which results in SSSD restarting the backend entirely: diff --git a/src/providers/ipa/ipa_subdomains_ext_groups.c b/src/providers/ipa/ipa_subdomains_ext_groups.c index 90460bc..1e2e0c2 100644 --- a/src/providers/ipa/ipa_subdomains_ext_groups.c +++ b/src/providers/ipa/ipa_subdomains_ext_groups.c @@ -867,9 +867,9 @@ static void ipa_add_ad_memberships_get_next(struct tevent_req *req) val = ldb_dn_get_rdn_val(group_dn); if (val == NULL || val->data == NULL) { DEBUG(SSSDBG_OP_FAILURE, - "Invalid group DN [%s].\n", state->groups[state->iter]); - ret = EINVAL; - goto fail; + "Invalid group DN [%s]. Skipping\n", state->groups[state->iter]); + state->iter++; + ipa_add_ad_memberships_get_next(req); } fq_name = (const char *) val->data; I suspect I am missing something obvious with the tevent flow occurring here, I was hoping for some guidance on this. Kind regards, Justin Stephenson

1 0

[sssd PR#109][opened] SSSCTL: fix netgroup-show parsing
by fidencio 12 Jan '17

12 Jan '17

URL: https://github.com/SSSD/sssd/pull/109 Author: justin-stephenson Title: #109: SSSCTL: fix netgroup-show parsing Action: opened PR body: """ the ldb Name attribute is not fully-qualified for netgroups like it is for user and group objects, sssctl should skip sss_output_name() for netgroup entries. Resolves: https://fedorahosted.org/sssd/ticket/3267 -- Reproduced easily by adding a netgroup(in IDM or otherwise), getent netgroup <netgroupname>, sssctl netgroup-show <netgroupname> """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/109/head:pr109 git checkout pr109

2 22

Handling of offline requests in sssd-1-13 and older
by Jakub Hrozek 11 Jan '17

11 Jan '17

Hi, there was a customer complaining about fail over not reconnecting as fast with sssd-1-13 as it did with sssd-1-14. The issue they were seeing was that if sssd was offline, but the server came back up, it still took sssd the full offline timeout cycle to attempt to reconnect, even though we say that auth attempts are always done against the server. I traced it to the difference in handling the offline state in the providers themselves. With sssd-1-14, the only place that decides whether to contact the providers is the DP itself. If the fast flag is set and the provider is offline, we always return the offline error, if the fast flag is unset, we ask the provider. Now, the difference is that in sssd-1-13, we also have this code: https://github.com/jhrozek/sssd/commit/397f956365dd320194c792c372625cdfdaa3… that would shortcut the request w/o trying to connect if the back end was offline. I think this code is wrong and what sssd-1-14 does is correct. Therefore, I would like to just nuke the code that checks if the back end is offline from the providers and let them always reconnect -- but I'm not sure if this is safe to do in the LTM branch. In theory, laptop users could complain about too frequent reconnects, however, I haven't seen any complains with sssd-1-14 so far. Opinions?

1 0

Group renaming issue when "id_provider = ldap" is set.
by Fabiano Fidêncio 10 Jan '17

10 Jan '17

I've been working on rhbz#1401241 (https://bugzilla.redhat.com/show_bug.cgi?id=1401241) and I'd like to clarify some doubts that showed up. So, let's consider that there's a group called "foo" and user "user" is part of this group. Group "foo" gets renamed to "bar'. Now. let me describe what I've found out considering "id_provider = ldap" and "id_provider = ad" - id_provider = ldap: cache has "foo" entry After renaming "foo" to "bar" cache has entry "bar" added both entries have the same gid - id_provider = ad cache has "foo" entry After renaming "foo" to "bar" nothing is changed in the cache Any of these situation look exactly right for me (and here I'm probably wrong). My expectations are that we should, for both cases: - check for the gid in the cache - update the entry So in the ldap case we would avoid having two entries with the same gid and in the ad case we would be able to properly the updated name of the group that the user is part of. Does it make sense? Summing up the questions: - When a group has its name changed, shall we update the entry that contains its name (and then all memberOf that contains the old name?)? - In case not, following what "id_provider = ad" does would be a good fix for the issue? Looking forward to hearing your opinion! Best Regards, -- Fabiano Fidêncio

2 3

[sssd PR#113][opened] Adds an integration test for sssctl netgroup-show so that we don't regress again like we did in ticket #3267.
by fidencio 10 Jan '17

10 Jan '17

URL: https://github.com/SSSD/sssd/pull/113 Author: jhrozek Title: #113: Adds an integration test for sssctl netgroup-show so that we don't regress again like we did in ticket #3267. 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/113/head:pr113 git checkout pr113

1 9

[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

RFC: Socket-activation, some changes in the architecture.
by Fabiano Fidêncio 09 Jan '17

09 Jan '17

People, Recently I've faced some issues when testing the socket-activation working running as sssd-user, which will force me to take a different path for a few things and I really would like to know your opinion on those things. So, currently, this is what the nss.service looks like: [Unit] Description=SSSD NSS Service responder Documentation=man:sssd.conf(5) After=sssd.service BindsTo=sssd.service [Install] Also=sssd-nss.socket [Service] ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath@/sssd_nss.log ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start Restart=on-failure User=@SSSD_USER@ Group=@SSSD_USER@ PermissionsStartOnly=true As you probably noticed, I've been using systemd's machinery to change the debug files' owner and to start the responder by the proper user (sssd or root). Well, it doesn't work that well as expected as systemd ends up calling initgroups(sssd, ...) in order to start any service using "sssd" user and this call is done _before_ starting the NSS responder, which will hang for the "default client timeout" (300s). Okay, we have to change it and here is where I need your help! - Adding a new "sssd-user" option: By adding this option we could just start the responders calling: libexecdir@/sssd/sssd_nss --debug-to-files --sssd-user=@SSSD_USER@. The unit file would be changed a little as the ExectStartPre, User and Group options could just go away. The server code would be changed a little in order to invoke setenv("_SSS_LOOPS", "NO", 0) earlier, as done here: index 52e6ed7..013e572 100644 --- a/src/util/server.c +++ b/src/util/server.c @@ -461,8 +461,6 @@ int server_setup(const char *name, int flags, char *locale; int watchdog_interval; - setenv("_SSS_LOOPS", "NO", 0); - ret = chown_debug_file(NULL, uid, gid); if (ret != EOK) { DEBUG(SSSDBG_MINOR_FAILURE, @@ -481,6 +479,8 @@ int server_setup(const char *name, int flags, return ENOMEM; } + setenv("_SSS_LOOPS", "NO", 0); + /* To make sure the domain cannot be set from the environment, unset the * variable explicitly when setting up any server. Backends later set the * value after reading domain from the configuration */ Also, the server_setup() would receive the user passed to --sssd-user and perform a getpwnam() in order to get the uid/gid and then be able to change debug files' owner and become the user, as done here: diff --git a/src/util/server.c b/src/util/server.c index c9a2726..d9da803 100644 --- a/src/util/server.c +++ b/src/util/server.c @@ -445,6 +445,7 @@ static const char *get_pid_path(void) int server_setup(const char *name, int flags, uid_t uid, gid_t gid, + char *sssd_user, const char *conf_entry, struct main_context **main_ctx) { @@ -463,6 +464,22 @@ int server_setup(const char *name, int flags, setenv("_SSS_LOOPS", "NO", 0); + if (sssd_user != NULL) { + struct passwd *pw; + + pw = getpwnam(sssd_user); + if (pw == NULL) { + DEBUG(SSSDBG_MINOR_FAILURE, + "Cannot get the information about the user %s. " + "The process will be run as root\n", sssd_user); + uid = 0; + gid = 0; + } else { + uid = pw->pw_uid; + gid = pw->pw_gid; + } + } + ret = chown_debug_file(NULL, uid, gid); Okay, okay. It would work. Would it be okay for the rest of the developers? Considering that it will be okay ... doesn't it look a little bit weird/inconsistent passing the sssd-user sometimes and passing the uid/gid in the most part of the times? Wouldn't be better just pass the sssd-user all the time and do the getpwnam() call here instead of doing it in the monitor when starting it? Now, considering we will user "--sssd-user" when calling the responders ... I can take advantage of this in case we _only_ use this option when socket-activating the responders, as the responder will know from the beginning whether it was socket activated or explicitly started (and it's useful for shutting down the responder when it's inactive). Another option (that I personally prefer) is having, again, a new option "--socket-activated" that would make things clear for whoever ends up taking care of this code later on (probably the future me). Would that be okay? So, summing up the questions ... - Is there any problem on calling 'setenv("_SSS_LOOPS", "NO", 0)' earlier in the process? - Would be okay adding "--sssd-user" option for starting the responders? - Shall I get rid of the "--uid and --gid" options in order to only use the new added "--sssd-user" one? - Shall I add a new "--socket-activated" option for starting the responders or just abuse the "--sssd-user" one? Looking forward to hearing your opinions! Best Regards, -- Fabiano Fidêncio

5 12

[sssd PR#100][opened] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds
by fidencio 06 Jan '17

06 Jan '17

URL: https://github.com/SSSD/sssd/pull/100 Author: amitkumar50 Title: #100: Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds Action: opened PR body: """ https://fedorahosted.org/sssd/ticket/2201 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/100/head:pr100 git checkout pr100

2 25

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

06 Jan '17

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

1 21

[sssd PR#118][opened] Don't keep track of automatically generated files
by fidencio 05 Jan '17

05 Jan '17

URL: https://github.com/SSSD/sssd/pull/118 Author: fidencio Title: #118: Don't keep track of automatically generated files Action: opened PR body: """ Those files are automatically generated on every build. There's no reason to keep track of them in our tree. 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/118/head:pr118 git checkout pr118

1 8

radius authentication through sssd
by Vijayakumar Kannan 04 Jan '17

04 Jan '17

Greetings, OS running on rhel7.3 platform using sssd integrated with AD authentication is working as expected. In my environment I have OTP (one time password) server on radius solution. How do I use the SSSD to forward the authentication to radius server for ssh authentication? Also how I can enable 2 step password prompt 1st prompt for AD validation and 2nd prompt for OTP validation(radius)? Regards, Vijay Qatar Airways - Going Places Together Disclaimer:- This message (including attachments) is intended solely for the addressee named above. It may be confidential, privileged, subject to copyright, trade secret, or other legal rules and may not be forwarded without the author's permission. If you are not the addressee you must not read, copy or disseminate this message. If you have received it in error please notify the sender immediately and delete the message from all storage devices. Any opinions expressed in this message do not necessarily represent the official positions of Qatar Airways. Any agreements (including any warranties, representations, or offers) concluded with Qatar Airways by using electronic correspondence shall only come into existence if an authorized representative of Qatar Airways has explicitly approved such contract formation. To the fullest extent permissible by law, Qatar Airways disclaim all liability for loss or damage to person or property arising from this message being infected by computer virus or other contamination.

1 0

RFC: Configuration of trusted domain (a.k.a. subdomain) in sssd.conf
by Michal Židek 04 Jan '17

04 Jan '17

Hi, for IPA provider, we plan to add the ability to configure trusted domains (currently AD domains) in a similar way the main domain is configured in sssd.conf. If ipadomain.test is the main IPA domain and addomain.test is the AD domain and there is IPA-AD trust extablished between the two, I think the way to configure addomain.test specific option could be: [domain/ipadomain.com] # the usual main domain configuration [domain/ipadomain.com/addomain.com] # configuration of trusted domain So, the main domain would be used as prefix in the section name where the trusted domain / subdomain is configured. I wanted to ask what other developers think about the format. Note that not all options that are available in the main domain will be available for the subdomain. Michal

4 4

[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

[sssd PR#116][opened] intg: Generate tmp dir with lowercase
by fidencio 02 Jan '17

02 Jan '17

URL: https://github.com/SSSD/sssd/pull/116 Author: lslebodn Title: #116: intg: Generate tmp dir with lowercase Action: opened PR body: """ This is a workaround for buggy python-requests 2.12.4. It cannot handle uppercase letters in file path. The manual page MKTEMP(1) says that the parameter --dry-run is unsafe. It is not critical for our use-case in CI but we should revert the patch after fixed version of puython-request will be released The broken version of python-requests (2.12.4) is in fedora rawhide and debian testing + """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/116/head:pr116 git checkout pr116

1 7

[sssd PR#117][opened] Fix compilation with python3.6
by fidencio 02 Jan '17

02 Jan '17

URL: https://github.com/SSSD/sssd/pull/117 Author: lslebodn Title: #117: Fix compilation with python3.6 Action: opened PR body: """ Autotools does not generate defines in conditional way (ifndef .. define) and therefore it might happen that "defines" in config.h migt redefine some macros in different way and generate a warning. e.g. In file included from /home/build/sssd/src/util/util.h:24:0, from /home/build/sssd/src/python/pyhbac.c:24: ./config.h:322:0: error: "HAVE_LONG_LONG" redefined [-Werror] #define HAVE_LONG_LONG 1 In file included from /usr/include/python3.6m/Python.h:50:0, from /home/build/sssd/src/python/pyhbac.c:21: /usr/include/python3.6m/pyport.h:42:0: note: this is the location of the previous definition #define HAVE_LONG_LONG We need to include config.h before Python.h to avoid redefinition of HAVE_LONG_LONG which is definded conditionally in Python.h """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/117/head:pr117 git checkout pr117

1 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel January 2017