| 2018-12-06 18:14:18 |
Luke Schierer |
bug |
|
|
added bug |
| 2018-12-07 06:53:58 |
Christian Ehrhardt |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2018-12-07 07:04:51 |
Christian Ehrhardt |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1359208 |
|
| 2018-12-07 07:04:55 |
Christian Ehrhardt |
sssd (Ubuntu): status |
New |
Incomplete |
|
| 2018-12-10 10:10:35 |
Christian Ehrhardt |
bug |
|
|
added subscriber Andreas Hasenack |
| 2018-12-17 13:25:02 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2019-01-07 10:14:09 |
Robie Basak |
sssd (Ubuntu): status |
Incomplete |
Triaged |
|
| 2019-01-07 10:14:20 |
Robie Basak |
tags |
amd64 apport-bug bionic ec2-images |
amd64 apport-bug bionic ec2-images server-next |
|
| 2019-01-08 18:24:19 |
Andreas Hasenack |
sssd (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2019-01-08 18:24:23 |
Andreas Hasenack |
sssd (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-01-08 18:24:25 |
Andreas Hasenack |
sssd (Ubuntu): status |
Triaged |
In Progress |
|
| 2019-01-16 19:03:57 |
Andreas Hasenack |
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) |
[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]
* 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.
[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) |
|
| 2019-01-16 19:12:53 |
Andreas Hasenack |
description |
[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]
* 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.
[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) |
[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:
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: testuser1@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
^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 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) |
|
| 2019-01-16 19:15:40 |
Andreas Hasenack |
description |
[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:
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: testuser1@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
^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 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) |
[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
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@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
^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 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) |
|
| 2019-01-16 19:16:40 |
Andreas Hasenack |
description |
[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
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@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
^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 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) |
[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: testuser1@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. 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) |
|
| 2019-01-16 19:17:27 |
Andreas Hasenack |
description |
[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: testuser1@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. 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) |
[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: testuser1@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. 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) |
|
| 2019-01-16 19:20:53 |
Andreas Hasenack |
description |
[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: testuser1@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. 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) |
[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: testuser1@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) |
|
| 2019-01-16 19:21:29 |
Andreas Hasenack |
description |
[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: testuser1@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) |
[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 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@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) |
|
| 2019-01-16 19:31:44 |
Andreas Hasenack |
description |
[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 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@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) |
[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.
[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@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) |
|
| 2019-01-16 19:35:02 |
Andreas Hasenack |
description |
[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.
[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@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) |
[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: testuser1@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) |
|
| 2019-01-16 19:42:01 |
Andreas Hasenack |
description |
[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: testuser1@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) |
[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: testuser1@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]
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]
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) |
|
| 2019-01-16 19:45:27 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/sssd/+git/sssd/+merge/361848 |
|
| 2019-01-22 21:40:47 |
Brian Murray |
sssd (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2019-01-22 21:40:49 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-01-22 21:40:51 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-01-22 21:40:56 |
Brian Murray |
tags |
amd64 apport-bug bionic ec2-images server-next |
amd64 apport-bug bionic ec2-images server-next verification-needed verification-needed-bionic |
|
| 2019-01-23 14:07:35 |
Luke Schierer |
tags |
amd64 apport-bug bionic ec2-images server-next verification-needed verification-needed-bionic |
amd64 apport-bug bionic ec2-images server-next verification-done-bionic verification-needed |
|
| 2019-01-30 18:58:28 |
Launchpad Janitor |
sssd (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-01-30 18:58:40 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-01-30 19:49:44 |
Andreas Hasenack |
sssd (Ubuntu): status |
In Progress |
Fix Released |
|
