[zokier]

> POSIX says usernames starting with a digit should be fine.

I'm not sure if POSIX has any relevance here. Afaik systemd isn't claiming any sort of POSIX compliance, nor is it targeting POSIX systems in general, in fact it is explicitly Linux-only.

[srett]

Yes I tried to do research on this on the past. Linux, as in "just the kernel", doesn't care about user name formats as far as I can tell. However, the Linux philosophy goes "try to adhere to POSIX where it makes sense, break it where we think it sucks", which isn't exactly a clear statement, but lead me to conclude that it might make sense to check what posix does, if anything, because everything else is user space, e.g. GNU (coreutils, adduser) and thus isn't tied to Linux. systemd should call into libc and let it deal with the username, so if any of the nsswitch backends think 0day is a valid username and returns a uidnumber, just use it and don't try to be extra clever.

[digi_owl]

Best i recall, the kernel will offer POSIX compliant interfaces, but then also offer parallel interfaces that fix potential problems.

Similarly they will retain previously introduced, but flawed, interfaces etc until they are damn sure that they are no longer in use.

[mjw1007]

In that case the systemd developers ought to have been thinking «usernames beginning with digits do exist in the wild on linux systems, therefore we should support them».

[ArneBab]

They just would have had to think "let’s do the safe thing — instead of just assuming everything goes well and potentially using the root user as fallback if we’re wrong".

It’s a mindset/philosophy problem, and that doesn’t change when bugs get fixed. It would require the devs to change, but that didn’t happen in the past decade, so we cannot just assume that it will happen in the next.

[db48x]

But you have to be root to install a systemd unit in the first place...

[CodeWriter23]

Doesn't mean I want systemd silently escalating my process to root when I think I've told it to contain privileges of the process to a specific userid. Clearly the correct behavior for such a program is to throw an error if it is rejecting a username for ANY reason, even when that reason is supported by stilted reasoning.

[digi_owl]

And?

What is going on here is that an admin thinks he has shored up the service defined in the service file, because hey, it runs. Only to later have the server 0wned because apparently it was running as root the whole time...

[chronid]

Breaking expectations is not a reasonable default.

[falcolas]

There are also user-level unit files; can this bug be triggered by those?

EDIT: No; it acts as if the 'User=' directive doesn't exist.