** 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. + sssd can be complicated to setup and test, not because of itself, but because of the additional services that need to be setup (ldap server, kerberos server, etc). I believe the inclusion of the current DEP8 tests together with this SRU helps detect regressions due to this update, and future updates after this one. + The real fix in this SRU is a one liner, merely the treatment of the max_id return code, which wasn't being handled before and meant the lookup would stop too early. This exists in cosmic and disco already, and no regressions have been spotted. [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 real fix is a one liner. If the SRU team prefers, I can change the patch to do just that, in the spirit of minimal changes necessary. [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
