Red Hat Insights can detect this issue
- Red Hat Enterprise Linux
- Are all numeric usernames allowed in RHEL?
- RHEL 8 is not allowing me to create an all-numeric user.
- Can I create an all numeric username in Red Hat Enterprise Linux 7?
- All numeric usernames in any version of Red Hat Enterprise Linux are not supported.
- Names that begin with a digit but also contain letters are not known to be a problem on Red Hat Enterprise Linux. However, in RHEL 7, it is important to test such cases where variation across distributions and across history means tools can make varying assumptions.
Red Hat Enterprise Linux 8
RHEL8 doesn't support creation of ALL numeric usernames though it was possible in RHEL6 and RHEL7. And there are no plans to allow creation of ALL numeric usernames in future release of RHEL8.
This is also mentioned in man-page of useradd command:
Usernames may contain only lower and upper case letters, digits, underscores, or dashes. They can end with a dollar sign. Dashes are not allowed at the beginning of the username. Fully numeric usernames and usernames . or .. are also disallowed. It is not recommended to use usernames beginning with . character as their home directories will be hidden in the ls output. In regular expression terms: [a-zA-Z0-9_.][a-zA-Z0-9_.-]*[$]?
Red Hat Enterprise Linux 7
User and group names that consist only of digits, while permitted by
shadow-utils, are best avoided or treated with caution. Some tools (eg
getent) will be unable to recognise them at all, while others will need to be used carefully (eg
shadow-utils-184.108.40.206-25(shipped with Red Hat Enterprise Linux 7.6) does not allow to create all-numeric usernames.
shadow-utils-220.127.116.11-25.el7_6.1and later (shipped with Red Hat Enterprise Linux 7.6 batch update 3) requires the environment variable
SHADOW_ALLOW_ALL_NUMERIC_USERto be set to any value to allow the useradd command to create all-numeric usernames.
Over a decade ago, a patch was introduced to
shadow-utilsin Fedora to better support Samba 3.x machine usernames that end with '$'. At the same time, names were allowed to begin with a digit - including purely numeric usernames. This patch was picked up in Red Hat Enterprise Linux.
In 2014, Fedora added a restriction to coreutils to forbid pure numeric usernames. This change was evaluated for Enterprise Linux, but deemed too invasive to release to customers who may have come to rely on numeric usernames. Some customers facing problems using such usernames were advised to avoid them, but we could not simply release an update that could break people's systems.
While all-numeric usernames are not forbidden by POSIX, they can introduce ambiguity. Many programs will not care - they're either manipulating a string or an integer, and will do the right thing in each case. But CLI tools receive all their inputs as strings, so they have to make assumptions about whether "1001" should be treated as an integer UID or as a string username.
coreutilsis one such example: it will first try to interpret a user string as a name (using
getpwnam(3)) and then if that fails, try to parse it as a (decimal) number. Thus, scripts that do
chown 0 filenameto ensure a file is owned by root can be subverted if a user called
0is later added to the system. To disambiguate these cases,
coreutilssupports prefixing user/group identifiers with
+to ensure they are interpreted numerically . Other tools that have trouble with numeric user names include Access Control Lists (
The problem is potentially also present for usernames that begin with digits, when interpreted by programs that are not very careful with library calls.
3with no warning.
strtoul(3)is safer, but only if the
endptrargument is checked after the call to ensure the whole input was consumed.
systemd's behaviour here is a little eccentric, and has changed rapidly in recent years. As Lennart Poettering explains towards the end of the bug report, systemd "generally follow(s) the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons". This seems a reasonable choice for "pid 1", but the behaviour was surprising to the user who expected
User=0dayto be valid.
Note that the first conclusion reached in the bug report is incorrect: uid 0 is chosen for any syntactically invalid
User=line - it would be the same for a user called
This function also exists in
systemd-219used in Red Hat Enterprise Linux 7, but it is not applied to usernames in unit files.
Red Hat Enterprise Linux 7
- A bug report against systemd-232 discovered that usernames beginning with a number (such as "0day" or "3dogs") are not handled correctly in systemd unit files. Services assigned to such users will instead be started as
- This does not occur on systemd-219 as shipped in Red Hat Enterprise Linux 7. As the following test demonstrates, such usernames will be handled safely whether the corresponding user exists or not:
# cd /etc/systemd/system # cat test.service [Service] ExecStart=/usr/bin/id User=0day # grep 0day /etc/passwd # systemctl start test.service ... ... Failed at step USER spawning /bin/id: No such process ... # adduser 0day ... ... new user: name=0day, UID=1003, GID=1003, home=/home/0day, shell=/bin/bash ... # systemctl start test.service ... ... id: uid=1003(0day) gid=1003(0day) groups=1003(0day) context=system_u:system_r:unconfined_service_t:s0 ...
- Comments in the bug report did identify that while many distributions deny usernames beginning with numbers, Red Hat Enterprise Linux has a special patch in
shadow-utilsthat permits such usernames. This article examines the background and implications of that patch.
- Red Hat Enterprise Linux
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.