@pam-s, as soon as you can confirm this patch fixes your problem (feel free to use my PPA packages), please let us know so we can proceed with the SRU.
My test case reproduces the segfault, but I would like to be sure it also fixes it in your environment before continuing. Thanks again ** Description changed: [Impact] In this particular configuration, when ldap_rfc2307_fallback_to_local_users is set to true in /etc/sss/sssd.conf and a local user is a member of an ldap group and does not exist in the directory (other scenarios are possible), the sssd_be process segfaults and logins might be prevented. The original scenario is a bit more complex and involves setting up an Active Directory server, but with the help from the bug reporter (thanks @pam-s!) we managed to narrow it down to this simple test case. [Test Case] # Install the packages. When prompted, choose any password for the ldap admin $ sudo apt update; sudo apt install sssd slapd # create the sssd config $ sudo tee /etc/sssd/sssd.conf <<EOF [sssd] config_file_version = 2 services = nss, pam domains = LDAP [domain/LDAP] id_provider = ldap ldap_uri = ldap://localhost ldap_search_base = dc=example,dc=com ldap_rfc2307_fallback_to_local_users = True EOF $ sudo chmod 0600 /etc/sssd/sssd.conf # reconfigure slapd for domain example.com, organization example. For the rest, accept defaults $ sudo dpkg-reconfigure slapd # add the base ldif. When prompted, use the password you chose when reconfiguring slapd earlier $ ldapadd -x -D cn=admin,dc=example,dc=com -W <<EOF dn: ou=People,dc=example,dc=com ou: People objectClass: organizationalUnit dn: ou=Group,dc=example,dc=com ou: Group objectClass: organizationalUnit dn: cn=ldapusers,ou=Group,dc=example,dc=com cn: ldapusers objectClass: posixGroup gidNumber: 10000 memberUid: localuser EOF adding new entry "ou=People,dc=example,dc=com" adding new entry "ou=Group,dc=example,dc=com" adding new entry "cn=ldapusers,ou=Group,dc=example,dc=com" # create a localuser with that name $ sudo useradd -M localuser # restart sssd $ sudo service sssd restart # take note of the sssd_be process id: $ pidof sssd_be 15474 # in one terminal, keep tailing /var/log/syslog $ sudo tail -f /var/log/syslog # in another terminal, run this id command. It will possibly hang for a bit, and won't show the "ldapusers" group membership $ id localuser (hangs a bit) uid=1001(localuser) gid=1001(localuser) groups=1001(localuser) - # /var/log/syslog will emit messages like these, about a crash and sssd_be restarting (if you don't have apport installed, you will just see the "starting up" bit about sssd_be): Nov 6 17:17:08 xenial-sssd-bad-initgroups-result-1684295 systemd[1]: Starting Apport crash forwarding receiver... Nov 6 17:17:08 xenial-sssd-bad-initgroups-result-1684295 sssd[be[LDAP]]: Starting up Nov 6 17:17:08 xenial-sssd-bad-initgroups-result-1684295 systemd[1]: Started Apport crash forwarding receiver. # verify that the sssd_be process id changed, confirming that it crashed and was restarted: $ pidof sssd_be 15485 # install the fixed packages from proposed $ apt install/dist-upgrade .... # repeat the id command. Now it finishes quickly, shows the "ldapusers" group membership, and there won't be any sign of an sssd_be restart in /var/log/syslog: $ id localuser uid=1001(localuser) gid=1001(localuser) groups=1001(localuser),10000(ldapusers) + [Regression Potential] + The patch is very specific, but given in how many different ways sssd can be configured, it would really help if users actually tested the package from proposed in their deployments. Specially considering it's a login service. - [Regression Potential] - - * discussion of how regressions are most likely to manifest as a result - of this change. - - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + That being said, the patch is applied in the 1.13, 1,14 and current 1.15 + series upstream and is more than a year old by now. It could rely on + other changes that I missed, though, but at least one I chose to ignore + (see [other info]). [Other Info] - - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance + The exact upstream patch wasn't applied (https://pagure.io/SSSD/sssd/c/5a0fb268e836e600d864ded7de5d935946ae6c61), because it relied on dropping an unused parameter from sdap_fallback_local_user(), namely the *opts struct pointer (https://pagure.io/SSSD/sssd/c/77f960ab32c2d2245fed55671f24af287ea0ba50). It is indeed not used, but I rather not drop it for an SRU because I don't know if some library could be using it, and also because a new upstream version for this series (1.13.5) wasn't released yet with this change. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1684295 Title: sssd fails with 'Exiting the SSSD. Could not restart critical service [tpad]. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1684295/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
