| 2021-05-04 10:36:47 |
Victor Tapia |
bug |
|
|
added bug |
| 2021-05-04 10:40:07 |
Victor Tapia |
nominated for series |
|
Ubuntu Groovy |
|
| 2021-05-04 10:40:07 |
Victor Tapia |
bug task added |
|
shadow (Ubuntu Groovy) |
|
| 2021-05-04 10:40:07 |
Victor Tapia |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-05-04 10:40:07 |
Victor Tapia |
bug task added |
|
shadow (Ubuntu Hirsute) |
|
| 2021-05-04 10:40:07 |
Victor Tapia |
nominated for series |
|
Ubuntu Focal |
|
| 2021-05-04 10:40:07 |
Victor Tapia |
bug task added |
|
shadow (Ubuntu Focal) |
|
| 2021-05-04 10:40:07 |
Victor Tapia |
nominated for series |
|
Ubuntu Impish |
|
| 2021-05-04 10:40:07 |
Victor Tapia |
bug task added |
|
shadow (Ubuntu Impish) |
|
| 2021-05-10 15:32:16 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2021-05-10 17:55:26 |
Matthieu Clemenceau |
tags |
|
fr-1357 |
|
| 2021-05-10 19:10:04 |
Steve Beattie |
bug |
|
|
added subscriber Steve Beattie |
| 2021-05-11 16:59:35 |
Jay Vosburgh |
bug |
|
|
added subscriber Jay Vosburgh |
| 2021-06-15 20:42:04 |
William Wilson |
shadow (Ubuntu Impish): assignee |
|
William Wilson (jawn-smith) |
|
| 2021-06-16 20:57:18 |
William Wilson |
attachment added |
|
lp1927078.debdiff https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5505076/+files/lp1927078.debdiff |
|
| 2021-06-16 21:15:39 |
Steve Langasek |
bug |
|
|
added subscriber Steve Langasek |
| 2021-06-17 00:41:00 |
Ubuntu Foundations Team Bug Bot |
tags |
fr-1357 |
fr-1357 patch |
|
| 2021-06-17 00:41:13 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2021-06-17 21:08:05 |
William Wilson |
attachment added |
|
Disallow Fully Numeric Patch https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5505363/+files/lp1927078_fully_numeric.debdiff |
|
| 2021-06-18 19:06:03 |
Brian Murray |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2021-06-18 19:26:26 |
Mathew Hodson |
shadow (Ubuntu Focal): importance |
Undecided |
Low |
|
| 2021-06-18 19:26:28 |
Mathew Hodson |
shadow (Ubuntu Groovy): importance |
Undecided |
Low |
|
| 2021-06-18 19:26:31 |
Mathew Hodson |
shadow (Ubuntu Hirsute): importance |
Undecided |
Low |
|
| 2021-06-18 19:26:33 |
Mathew Hodson |
shadow (Ubuntu Impish): importance |
Undecided |
Low |
|
| 2021-07-07 22:25:51 |
William Wilson |
attachment added |
|
Fully numeric and more tests patch https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5509701/+files/lp1927078_fully_numeric.debdiff |
|
| 2021-07-07 22:27:21 |
William Wilson |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2021-07-09 21:12:52 |
William Wilson |
attachment added |
|
invalid hexadecimal and floating point https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5510089/+files/lp1927078_fully_numeric_and_hex.debdiff |
|
| 2021-07-12 14:38:51 |
William Wilson |
attachment added |
|
Octal included this time https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5510554/+files/lp1927078_fully_numeric_and_hex_and_octal.debdiff |
|
| 2021-07-12 19:24:13 |
William Wilson |
attachment added |
|
Removed float checks https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5510618/+files/lp1927078_removed_float_checks.debdiff |
|
| 2021-07-13 15:48:15 |
Launchpad Janitor |
shadow (Ubuntu Impish): status |
New |
Fix Released |
|
| 2021-07-14 21:51:10 |
William Wilson |
description |
[Description]
Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples:
1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it:
root@focal:/home/ubuntu# useradd -m 0
root@focal:/home/ubuntu# id 0
uid=1005(0) gid=1005(0) groups=1005(0)
..
0@192.168.122.6's password:
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)
Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1
$ loginctl
No sessions.
$ w
16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
0 pts/0 192.168.122.1 16:17 0.00s 0.00s 0.00s w
And pam-systemd shows the following message:
Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0)
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login.
Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent.
[Other info]
- Upstream does not support fully numeric usernames
- useradd has a --badnames parameter that would still allow the use of these type of names |
[Impact]
* If a fully numeric username is created, it will cause
problems with systemd. One example is that the user with
this type of name can log in, but loginctl will not create
a session for them.
* This can also cause users to be unable to log in to a gdm
environment
[Test Case]
* `useradd 123` (this command should succeed)
* `userdel 123` to clean up the user that was just added
* Install `shadow` from -proposed
* `useradd 123` should now fail
[Regression Potential]
* If there were a logic error in the fix, it is possible
that valid usernames would now be disallowed.
* Many test cases have been added to ensure this is not
the case, and --badnames would still provide a work-around
[Original Description]
Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples:
1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it:
root@focal:/home/ubuntu# useradd -m 0
root@focal:/home/ubuntu# id 0
uid=1005(0) gid=1005(0) groups=1005(0)
..
0@192.168.122.6's password:
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)
Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1
$ loginctl
No sessions.
$ w
16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
0 pts/0 192.168.122.1 16:17 0.00s 0.00s 0.00s w
And pam-systemd shows the following message:
Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0)
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login.
Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent.
[Other info]
- Upstream does not support fully numeric usernames
- useradd has a --badnames parameter that would still allow the use of these type of names |
|
| 2021-07-14 22:56:47 |
William Wilson |
shadow (Ubuntu Hirsute): assignee |
|
William Wilson (jawn-smith) |
|
| 2021-07-14 22:56:49 |
William Wilson |
shadow (Ubuntu Focal): assignee |
|
William Wilson (jawn-smith) |
|
| 2021-07-14 22:56:56 |
William Wilson |
shadow (Ubuntu Hirsute): status |
New |
In Progress |
|
| 2021-07-14 22:56:58 |
William Wilson |
shadow (Ubuntu Focal): status |
New |
In Progress |
|
| 2021-07-14 23:01:44 |
Brian Murray |
shadow (Ubuntu Groovy): status |
New |
Won't Fix |
|
| 2021-07-14 23:06:12 |
William Wilson |
attachment added |
|
Hirsute Patch https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5510996/+files/lp1927078_hirsute.debdiff |
|
| 2021-07-14 23:06:49 |
William Wilson |
attachment added |
|
Focal SRU https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+attachment/5510997/+files/lp197078_focal.debdiff |
|
| 2021-07-14 23:07:05 |
William Wilson |
shadow (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2021-07-14 23:07:07 |
William Wilson |
shadow (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
| 2021-07-15 08:20:20 |
Lukas Märdian |
shadow (Ubuntu Focal): status |
Fix Committed |
In Progress |
|
| 2021-07-15 08:20:23 |
Lukas Märdian |
shadow (Ubuntu Hirsute): status |
Fix Committed |
In Progress |
|
| 2021-07-21 14:13:51 |
Robie Basak |
description |
[Impact]
* If a fully numeric username is created, it will cause
problems with systemd. One example is that the user with
this type of name can log in, but loginctl will not create
a session for them.
* This can also cause users to be unable to log in to a gdm
environment
[Test Case]
* `useradd 123` (this command should succeed)
* `userdel 123` to clean up the user that was just added
* Install `shadow` from -proposed
* `useradd 123` should now fail
[Regression Potential]
* If there were a logic error in the fix, it is possible
that valid usernames would now be disallowed.
* Many test cases have been added to ensure this is not
the case, and --badnames would still provide a work-around
[Original Description]
Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples:
1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it:
root@focal:/home/ubuntu# useradd -m 0
root@focal:/home/ubuntu# id 0
uid=1005(0) gid=1005(0) groups=1005(0)
..
0@192.168.122.6's password:
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)
Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1
$ loginctl
No sessions.
$ w
16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
0 pts/0 192.168.122.1 16:17 0.00s 0.00s 0.00s w
And pam-systemd shows the following message:
Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0)
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login.
Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent.
[Other info]
- Upstream does not support fully numeric usernames
- useradd has a --badnames parameter that would still allow the use of these type of names |
[Impact]
* If a fully numeric username is created, it will cause
problems with systemd. One example is that the user with
this type of name can log in, but loginctl will not create
a session for them.
* This can also cause users to be unable to log in to a gdm
environment
[Test Case]
* `useradd 123` (this command should succeed)
* `userdel 123` to clean up the user that was just added
* Install `shadow` from -proposed
* `useradd 123` should now fail
[Regression Potential]
* If there were a logic error in the fix, it is possible
that valid usernames would now be disallowed.
* Many test cases have been added to ensure this is not
the case, and --badnames would still provide a work-around
* [racb] Users may have scripts that are currently using numeric usernames and this scripts will break as a consequence of this deliberate change in stable Ubuntu releases. However, based on the discussion in the bug, we think this is preferable to leaving such users with unstable behaviour such as systemd's behaviour described.
[Original Description]
Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples:
1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it:
root@focal:/home/ubuntu# useradd -m 0
root@focal:/home/ubuntu# id 0
uid=1005(0) gid=1005(0) groups=1005(0)
..
0@192.168.122.6's password:
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)
Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1
$ loginctl
No sessions.
$ w
16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
0 pts/0 192.168.122.1 16:17 0.00s 0.00s 0.00s w
And pam-systemd shows the following message:
Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0)
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login.
Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent.
[Other info]
- Upstream does not support fully numeric usernames
- useradd has a --badnames parameter that would still allow the use of these type of names |
|
| 2021-07-21 14:14:15 |
Robie Basak |
description |
[Impact]
* If a fully numeric username is created, it will cause
problems with systemd. One example is that the user with
this type of name can log in, but loginctl will not create
a session for them.
* This can also cause users to be unable to log in to a gdm
environment
[Test Case]
* `useradd 123` (this command should succeed)
* `userdel 123` to clean up the user that was just added
* Install `shadow` from -proposed
* `useradd 123` should now fail
[Regression Potential]
* If there were a logic error in the fix, it is possible
that valid usernames would now be disallowed.
* Many test cases have been added to ensure this is not
the case, and --badnames would still provide a work-around
* [racb] Users may have scripts that are currently using numeric usernames and this scripts will break as a consequence of this deliberate change in stable Ubuntu releases. However, based on the discussion in the bug, we think this is preferable to leaving such users with unstable behaviour such as systemd's behaviour described.
[Original Description]
Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples:
1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it:
root@focal:/home/ubuntu# useradd -m 0
root@focal:/home/ubuntu# id 0
uid=1005(0) gid=1005(0) groups=1005(0)
..
0@192.168.122.6's password:
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)
Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1
$ loginctl
No sessions.
$ w
16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
0 pts/0 192.168.122.1 16:17 0.00s 0.00s 0.00s w
And pam-systemd shows the following message:
Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0)
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login.
Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent.
[Other info]
- Upstream does not support fully numeric usernames
- useradd has a --badnames parameter that would still allow the use of these type of names |
[Impact]
* If a fully numeric username is created, it will cause
problems with systemd. One example is that the user with
this type of name can log in, but loginctl will not create
a session for them.
* This can also cause users to be unable to log in to a gdm
environment
[Test Case]
* `useradd 123` (this command should succeed)
* `userdel 123` to clean up the user that was just added
* Install `shadow` from -proposed
* `useradd 123` should now fail
[Regression Potential]
* If there were a logic error in the fix, it is possible
that valid usernames would now be disallowed.
* Many test cases have been added to ensure this is not
the case, and --badnames would still provide a work-around
* [racb] Users may have scripts that are currently using numeric usernames and these scripts will break as a consequence of this deliberate change in stable Ubuntu releases. However, based on the discussion in the bug, we think this is preferable to leaving such users with unstable behaviour such as systemd's behaviour described.
[Original Description]
Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples:
1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it:
root@focal:/home/ubuntu# useradd -m 0
root@focal:/home/ubuntu# id 0
uid=1005(0) gid=1005(0) groups=1005(0)
..
0@192.168.122.6's password:
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64)
Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1
$ loginctl
No sessions.
$ w
16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
0 pts/0 192.168.122.1 16:17 0.00s 0.00s 0.00s w
And pam-systemd shows the following message:
Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0)
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing
Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login.
Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent.
[Other info]
- Upstream does not support fully numeric usernames
- useradd has a --badnames parameter that would still allow the use of these type of names |
|
| 2021-07-21 14:51:43 |
Robie Basak |
shadow (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
| 2021-07-21 14:51:44 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-07-21 14:51:46 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2021-07-21 14:51:49 |
Robie Basak |
tags |
fr-1357 patch |
fr-1357 patch verification-needed verification-needed-hirsute |
|
| 2021-07-21 14:52:38 |
Robie Basak |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2021-07-21 15:34:48 |
Robie Basak |
shadow (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2021-07-21 15:34:53 |
Robie Basak |
tags |
fr-1357 patch verification-needed verification-needed-hirsute |
fr-1357 patch verification-needed verification-needed-focal verification-needed-hirsute |
|
| 2021-07-21 16:49:07 |
William Wilson |
tags |
fr-1357 patch verification-needed verification-needed-focal verification-needed-hirsute |
fr-1357 patch verification-done-hirsute verification-needed verification-needed-focal |
|
| 2021-07-21 16:53:28 |
William Wilson |
tags |
fr-1357 patch verification-done-hirsute verification-needed verification-needed-focal |
fr-1357 patch verification-done verification-done-focal verification-done-hirsute |
|
| 2021-07-30 20:35:05 |
Brian Murray |
bug task added |
|
ubuntu-release-notes |
|
| 2021-08-02 13:10:23 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-08-02 13:18:59 |
Launchpad Janitor |
shadow (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
| 2021-08-02 13:46:35 |
Launchpad Janitor |
shadow (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-08-02 22:30:36 |
Brian Murray |
ubuntu-release-notes: status |
New |
Fix Released |
|
