[Bug 1684295] Re: sssd fails with 'Exiting the SSSD. Could not restart critical service [tpad].

Andreas Hasenack andreas at canonical.com
Mon Nov 6 17:44:55 UTC 2017


** 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.
  
-  * An explanation of the effects of the bug on users and
+ 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.
  
-  * justification for backporting the fix to the stable release.
- 
-  * In addition, it is helpful, but not required, to include an
-    explanation of how the upload fixes this bug.
  
  [Test Case]
  
-  * detailed instructions how to reproduce the bug
+  * detailed instructions how to reproduce the bug
  
-  * these should allow someone who is not familiar with the affected
-    package to reproduce the bug and verify that the updated package fixes
-    the problem.
+  * these should allow someone who is not familiar with the affected
+    package to reproduce the bug and verify that the updated package fixes
+    the problem.
  
  [Regression Potential]
  
-  * discussion of how regressions are most likely to manifest as a result
+  * 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.
+  * 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.
+  * This both shows the SRU team that the risks have been considered,
+    and provides guidance to testers in regression-testing the SRU.
  
  [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
+ 
+  * 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

** 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]
  
-  * detailed instructions how to reproduce the bug
+ # Install the packages. When prompted, choose any password for the ldap admin
+ $ sudo apt update; sudo apt install sssd slapd
  
-  * these should allow someone who is not familiar with the affected
-    package to reproduce the bug and verify that the updated package fixes
-    the problem.
+ # 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]
  
   * 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.
  
  [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

-- 
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



More information about the Ubuntu-server-bugs mailing list