Submission type

• Request for enhancement (RFE)

systemd version the issue has been seen with

systemd 232

…

Used distribution

Debian

…

In case of bug report: Expected behaviour you didn't see

Invalid user name causing unit to fail to run at all. Or at least an option to make invalid username result in unit not running at all. So unit has to be corrected before it run.

In case of bug report: Unexpected behaviour you saw

So user=0day or anything else invalid becoming run as higher privilege being root.

In case of bug report: Steps to reproduce the problem

Use useradd to create a user starting with a number like 0 day then attempt to use this name in a unit file and have it run as root when you were expecting it to run as a user without privillage . This will work in most distributions will explain way as it compatibility with samba.

I see this as a bug that 0day or anything like end up running as root. There should be an option of making user=0day anything else like it a failure unit state

With using samba NT4 mode I know that /etc/passwd can contain users starting with numbers because that is what windows allows.

On the various Linux distributions in various various different requirements are made on user name validity. Some distros/versions/adduser+useradd implementations have a stricter and others have a more vague definition of what a valid user name is. For systemd services, for the sake of compatiiblity with all implementions we are strict and require the rules that are compatible with all Linux implementations.

This is fine that is part a false statement.

In the same distributions adduser to reject username starting with numbers while useradd will be accept usernames starting with numbers and there is a reason for this being Samba. So majority of distributions are split brained on the point if a username can or cannot start with a number and this goes back to samba NT4 mode compatibility as it valid to name a machine in windows with a name starting with number and for that machine to connect it has to have a username in the /etc/passwd file in NT4 mode.

https://wiki.samba.org/index.php/Setting_up_Samba_as_an_NT4_PDC_(Quick_Start)

So any distribution that you cannot create a username start with a number with useradd is in fact conflict with samba in NT4 mode when you have to connect a windows computer with a windows valid machine name starting with a number effectively preventing connecting that machine.

Something else to remember is not required to user useradd or adduser to create or change user-names.

The issue is badly handling invalid syntax username. User=xxxx has normally been set to restrict privilege failure should never be raise privilege to max. If you want to run at least fail to non privileged account.

Then we'll ignore the assignment altogether (but log about it), since it's syntactically invalid.
This is wrong response. Syntactically invalid on items like user= should be either fail or restrict. There should be no difference in response be the username invalid by being non existing or syntactically invalid due to non acceptable lettering. Since non existing user but valid text is unit fail then syntactically invalid username should also be unit fail. The difference in response here is the bug. In fact adding a strict option to make all syntax invalid units fail would be useful.