** 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: testus...@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 * 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: testus...@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) -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1807246 Title: after upgrading to bionic, my session forgets who I am frequently To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1807246/+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
