Defaulting to root? Spawning a service defaults to .. the current user.
We can argue if User= lines should be validated more carefully or cause hard errors (vs warnings), but if you do not provide a valid User= line, the process will spawn with the current uid (which is 0 for initd).
Tempted to say it's a service, and the majority of these will want to run as root instead of any particular user. So in this sense the default makes sense.
So if someone spawns the torrent server as a restricted user to add a layer of security against problems in the server, and that user starts with a zero — like 0priviledge or 0pointer for that matter, do mind the domain of L. Pötterings blog — the service will launch as root, voiding the layer of protection?
Many of my services do not run as root for a reason.
You are erroneously conflating the default when there is no User= item with the default when there is a User= item but its value is neither a number nor a valid account in the user account database. The latter default is the item under discussion here.
The thing not being closed as "not a bug" before the situation is figured out (e.g. the opener had a user account starting with a 0, so it could be expected input) or clearer context is given (e.g. if systemd had an established policy on what a username is allowed to be, a reference to that)?
While understandable (maintainers are busy people and likely have to deal with a lot of reports that have clear cut answers), it sadly fits into the image people have of them.
I personally think "thumbs down" (since you referenced those) is a completely valid response to that – but to be clear, posting insults or other attacks is not!
Strict validation. If some option is not valid, fail loudly. And he still fails to acknowledge this is a security issue. Here's a scenario for you:
You're running a SaaS which spawns restricted demons/containers per customer, separating the users by assigning them local user accounts. One day, user "0zero" registers and their account has access to your whole environment. Would you expect this? Would you not classify this as a security issue?
root # chpst -u 0zero id
uid=1462(0zero) gid=1481(0zero) groups=1481(0zero)
root # setuidgid 0zero id
uid=1462(0zero) gid=1481(0zero) groups=1481(0zero)
root #
... I would not; I would. Both of these use the getpwnam() library function of course. Their behaviours are ...
root # chpst -u 0day id
chpst: fatal: unable to get password/group file entry: file does not exist
root # setuidgid 0day id
setuidgid: FATAL: 0day: No such user.
root #
... to abend when the account name is not found rather than continue on as the superuser without dropping privileges ...
We can argue if User= lines should be validated more carefully or cause hard errors (vs warnings), but if you do not provide a valid User= line, the process will spawn with the current uid (which is 0 for initd).