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 -- 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: New 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: New 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 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
