Comment 6 for bug 1927078

On Wed, Jun 16, 2021 at 09:15:32PM -0000, Steve Langasek wrote:
> Disallowing leading numeric digits entirely would, unfortunately,
> disable a significant class of valid usernames in conflict with
> historical usage.

Admins are still able to hand-edit /etc/passwd, /etc/shadow, and mv
home directory names if they've got a good enough reason to use such
names and trust their software to do the right thing.

> The main motivation in fixing this is that allowing fully-numeric
> usernames means there is ambiguity in contexts that can reference both
> uids and usernames and do not have strong typing. Aside from systemd,
> this is mostly about shells and invocations of various commandline
> tools; and neither bash nor the tools appear to interpret 0o0 or 0x0 as
> numbers:

I was thinking primarily of perl, here:

$ sudo perl -e 'print "muahaa\n" if $< == "0x0";'
muahaa

You could argue that wherever "0x0" came from in this perl program should
have kept track if it received a number or a name, but the language sure
doesn't help.

C examples are less compelling because it has types but the atoi(3)
and strtoul(3) APIs make it very easy to parse something like "2build"
or "4fun" or "0x0" into an integer. (strtol(3) has a nice example.)

> Let's please focus on the known problem case of all-numeric usernames.
> If there are other confirmed security issues with octal/hex
> representations of numbers, then we should also close those, but it
> needs a more precise fix than disabling leading digits.

How strongly do you feel about this? I can see where you're coming from,
but given (a) the escape hatch mechanism to 'break the rules' isn't too
onerous (b) the ease with which brittle code can be written (c) the
simplicity of 'deny leading digit' compared against 'make sure there's at
least one non-digit' or 'make sure there's at least one letter' etc I
prefer the simpler rule.

Thanks