Don't allow useradd to use fully numeric names

Bug #1927078 reported by Victor Tapia on 2021-05-04
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
shadow (Ubuntu)
Status tracked in Impish
Focal
Undecided
Unassigned
Groovy
Undecided
Unassigned
Hirsute
Undecided
Unassigned
Impish
Undecided
Unassigned

Bug 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

Julian Andres Klode (juliank) wrote :

Maybe it should be a warning in the SRUs as opposed to a failure, but I don't have a strong opinion. I'm a bit scared of breaking scripts. But maybe that's a good thing.

Victor Tapia (vtapia) wrote :

I don't have a strong opinion either, but given that scripts would ignore the warnings and the resulting numeric users are going to face random, seemingly unrelated issues thanks to the interaction with systemd, I think I prefer the failure.

FWIW, I've prepared a test version in a PPA[1] which keeps the rules from Debian[2] but prevents the fully numeric names. This is what it looks like:

$ useradd 0
useradd: invalid user name '0'

$ echo $?
3

$ sudo useradd 0c0

$ sudo useradd 0 --badnames

$ cat /etc/passwd | grep ^0
0c0:x:1001:1001::/home/0c0:/bin/sh
0:x:1002:1002::/home/0:/bin/sh

[1] https://launchpad.net/~vtapia/+archive/ubuntu/sf305373
[2] https://salsa.debian.org/debian/shadow/-/blob/master/debian/patches/506_relaxed_usernames

tags: added: fr-1357
Steve Beattie (sbeattie) wrote :

The Ubuntu Security team is +1 on disallowing purely numeric usernames, as they are too easily confused with UIDs.

I think our preference would be to disallow leading numeric digits entirely so that for example, 0x0 and 0o0 would be blocked as well, to try to prevent both user and programmatic confusion.

Probably adduser should also be made consistent with whatever change is made to useradd. The package provided adduser.conf files do have a NAME_REGEX option (in addition to the --force-badname option) but AFAICT is commented out by default (the commented out regex is "^[a-z][-a-z0-9_]*\$" but I'm not sure that's appropriate in a UTF-8 world.)

It would be good to have testcase and documentation for this captured somewhere.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers