[Bug 1807246] Re: after upgrading to bionic, my session forgets who I am frequently

Wed Jan 16 19:31:44 UTC 2019

** Description changed:

  [Impact]
+ When the max_id parameter is used in an sssd [domain], and a lookup is performed for a user with an id higher than that, and the cache expired, sssd fails to query that user in the other defined domains.

-  * An explanation of the effects of the bug on users and
- 
-  * 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.
+ The fix explicitly checks for the max_id case, letting the search
+ continue on to other domains, and was provided by upstream.

  [Test Case]

  * Install sssd, slapd and ldap-utils, on a bionic VM or LXD (if you get weird errors, use a VM, because the uid mapping in lxd might be conflicting with the uids chosen for this test):
  sudo apt update
  sudo apt install sssd slapd ldap-utils

  * Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password. For the rest, accept defaults:
  sudo dpkg-reconfigure slapd

  * Populate the ldap directory:
  ldapadd -x -D cn=admin,dc=example,dc=com -w secret -c <<EOF
  dn: ou=People,dc=example,dc=com
  ou: People
  objectClass: organizationalUnit

  dn: ou=Group,dc=example,dc=com
  ou: Group
  objectClass: organizationalUnit

  dn: uid=testuser1,ou=People,dc=example,dc=com
  uid: testuser1
  objectClass: inetOrgPerson
  objectClass: posixAccount
  cn: testuser1
  sn: testuser1
  givenName: testuser1
  mail: testuser1 at example.com
  userPassword: testuser1secret
  uidNumber: 10001
  gidNumber: 10001
  loginShell: /bin/bash
  homeDirectory: /home/testuser1

  dn: cn=testuser1,ou=Group,dc=example,dc=com
  cn: testuser1
  objectClass: posixGroup
  gidNumber: 10001
  memberUid: testuser1

  dn: cn=ldapusers,ou=Group,dc=example,dc=com
  cn: ldapusers
  objectClass: posixGroup
  gidNumber: 10100
  memberUid: testuser1

  EOF

  * Create /etc/sssd/sssd.conf with the following contents:
  [sssd]
  services = nss
  domains = local,example

  [nss]
  debug_level = 6
  memcache_timeout = 30

  [domain/local]
  id_provider = local
  enumerate = true
  max_id = 1000

  [domain/example]
  id_provider = ldap
  enumerate = true
  auth_provider = ldap
  ldap_uri = ldap://localhost
  ldap_search_base = dc=example,dc=com
  ldap_tls_reqcert = allow
  cache_credentials = true
  use_fully_qualified_names = false

  * Adjust permissions and restart:
  sudo chmod 0600 /etc/sssd/sssd.conf
  sudo systemctl restart sssd

  * Test:
  id testuser1

  Should return:
  uid=10001(testuser1) gid=10001 groups=10001,10100

  * Create a home directory:
  sudo mkdir /home/testuser1 -m 0700
  sudo chown testuser1:testuser1 /home/testuser1

  * Become testuser1 and run this script. Depending on how long ago was the sssd restart above, it should fail soon, at most in 40s:
  sudo -u testuser1 -i
  while /bin/true; do date; whoami || break; echo; sleep 10; done

  Wed Jan 16 19:12:02 UTC 2019
  testuser1
  ...

  Wed Jan 16 19:12:22 UTC 2019
  whoami: cannot find name for user ID 10001: Unknown error 1432158300

  With the fixed packages installed, that while loop won't be exited.

  [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

  [Original Description]
  I configured sssd on an Ubuntu 16.04 LTS system, and it worked just fine.  In fact, using the same sssd.conf file (which is managed by puppet) on un-upgraded system continues to work fine.

  However, after upgrading to 18.04.1 LTS, I find that the system is
  continuously forgetting who I am.  After a few commands, or a few
  minutes (I'm not sure exactly how many, but around 3-5 minutes) if I try
  to run sudo or whoami, it says that I am an unknown user.   for example,

  ```
  whoami
  whoami: cannot find name for user ID 2000: Unknown error 1432158300
  ```

  if I run the id command on my username, it returns the correct results,
  and whoami/sudo/other restricted commands will work again for a short
  time before forgetting who I am again.

  In the sssd_nss.log file, I see the lookup against the @local domain,
  but I do not see a related lookup in the ldap domain either in that log
  file or in the log file specific to the ldap domain.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: sssd 1.16.1-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
  Uname: Linux 4.15.0-42-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  Date: Thu Dec  6 12:30:43 2018
  Ec2AMI: ami-ea677d80
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: us-east-1c
  Ec2InstanceType: t2.small
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  SourcePackage: sssd
  UpgradeStatus: Upgraded to bionic on 2018-10-04 (63 days ago)

** Description changed:

  [Impact]
  When the max_id parameter is used in an sssd [domain], and a lookup is performed for a user with an id higher than that, and the cache expired, sssd fails to query that user in the other defined domains.

  The fix explicitly checks for the max_id case, letting the search
  continue on to other domains, and was provided by upstream.
+ 
+ The upstream patch was taken as is, including the whitespace changes and
+ the unit test, since those applied cleanly.
+ 
+ I'm additionally adding the existing Disco DEP8 tests for sssd to this
+ SRU, to facilitate testing for this update and subsequent ones. They
+ don't trip on specifically this case, but give more confidence in the
+ package since they test authentication (ldap and kerberos), ssl and user
+ and group lookups.

  [Test Case]

  * Install sssd, slapd and ldap-utils, on a bionic VM or LXD (if you get weird errors, use a VM, because the uid mapping in lxd might be conflicting with the uids chosen for this test):
  sudo apt update
  sudo apt install sssd slapd ldap-utils