** Description changed:

- [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
+  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  
+ 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.
  
- 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.
- 
+ 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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1927078

Title:
  Don't allow useradd to use fully numeric names

Status in shadow package in Ubuntu:
  Fix Released
Status in shadow source package in Focal:
  New
Status in shadow source package in Groovy:
  New
Status in shadow source package in Hirsute:
  New
Status in shadow source package in Impish:
  Fix Released

Bug 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to