** Description changed: [Impact] - * An explanation of the effects of the bug on users and + * An explanation of the effects of the bug on users and - * justification for backporting the fix to the stable release. + * 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. + * 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 + * Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit this test) + sudo apt update + sudo apt install sssd slapd ldap-utils - * 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. + * Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password: + sudo dpkg-reconfigure slapd + + * Populate the ldap directory: + ldapadd -x -D cn=admin,dc=example,dc=com -w secret + 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: [email protected] + 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 + + ^D + + * 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. It should fail at the 4th attempt, i.e., after about 40 seconds: + 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 + * 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 [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] * 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. [Test Case] * Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit 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: + * 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 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: [email protected] 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 ^D * Create /etc/sssd/sssd.conf with the following contents: [sssd] services = nss - domains = local,example + 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. It should fail at the 4th attempt, i.e., after about 40 seconds: 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] * 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. [Test Case] * Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit 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 + 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: [email protected] 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 - ^D + 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. It should fail at the 4th attempt, i.e., after about 40 seconds: 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] * 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. [Test Case] * Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit 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: [email protected] 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. It should fail at the 4th attempt, i.e., after about 40 seconds: 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] * 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. [Test Case] * Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit 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: [email protected] 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. It should fail at the 4th attempt, i.e., after about 40 seconds: + * 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] * 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. [Test Case] - * Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit this test) + * 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: [email protected] 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 Bugs, which is subscribed to Ubuntu. 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-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
