Hacker News Reader

Comment by grandinj | Hacker News Reader

I dont see any signs of "refuse to fix" there. I see a calm and reasonable discussion and an acknowledgement that some things need improving. Perhaps they refused to fix it in exactly the way the reporter wanted, but that's a far cry from arrogant refusal.

View on HN

Even if we accept their username definition, when a problem is detected (User= fails validation), the system shouldn't run the service as root (ignoring the user's clear intention to run as some specific UID).

The problem isn't the format of the usernames, it's that they detected an error, then ignored that the error happened while doing the opposite of what the user wanted. Failing the unit with an error would have been fine. Alternatively, proceeding with the indicated setuid(2) while warning about an invalid username would is also a sane response.

What I saw was poettering spouting garbage about what he thinks is an invalid user name (when in reality, it is not and common tools like useradd don't complain about it).

As the owner for a critical service like systemd (I don't use it, I prefer openRC on gentoo), he should know better.

grrr... your init system should not dictate what a valid username is. Your init system should use whatever users you've configured.

I don't like your name. Therefore you get root.

How on earth did this init system become so prevalent?

There was a whole hoo-hah in Debian over what to replace System 5 rc with: upstart, OpenRC, systemd, or something else. It got raised to the Technical Committee, sparked several resignations, went to a vote of the entire Debian Developer membership, and lasted for a long time.

* http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html

The Arch process was rather different:

* https://news.ycombinator.com/item?id=11834348

The Debian people did look at who develops the various systems, but they mainly just measured the developer count and what else was on each bandwagon. (See section 3.3 in Russ Allbery's evaluation, for example.) They didn't make any deeper evaluation extending to things such as the way that bugs got responded to in practice or what design steps people were taking to limit bugs.

Neither process was extensive enough to have spotted a User=0pointer gives superuser rights bug.

I was just venting... and you provided a great answer to my rhetorical question - which I found very interesting by the way.

I didn't see Russ' evaluation, but I get the point.

> your init system should not dictate what a valid username is

systemd is a task manager (which happens to manage init along with everything else it can and often cannot). Referring to systemd as an init system is just muddying well-tread waters by people who are lazily misunderstanding the technical issues. The problem with usernames is that there is no standard so schemes are OS specific. It's not really a systemd problem at the core. The systemd problem (because it almost always is badly implemented) is that it uses it's own username validation scheme that defaults to permissive root when the systemd scheme is not matched for configured services. Running on top of heterogeneous environments, you get inconsistent behavior (even when you comply with the OS). This would be like apache spawning handler threads as root if it doesn't like the username it's configured to run as, regardless if the username is valid under OSX and invalid under Fedora. Too bad, username schemes are now dictated by systemd, is Poettering's position.

The problem with usernames is that there is no standard

Yes there is: https://github.com/systemd/systemd/issues/6237#issuecomment-...

I'll just say that I strongly disagree. Pointing to the IEEE compatibility standard is being misleading. That's part of a standard and is not adequately inclusive to be considered "the standard". OS's that systemd supports do not all follow the POSIX standard. i.e. "not officially certified as POSIX compatible, comply in large part". Practically, this means some are more strict and other less so.

In regard to usernames, I can definitely forgive Poettering's initial failure in design to confusion. His assertion that he is following "the standard" fails on both a practical and logical level.

I am having a very hard time following your logic. You made an assertion about there being no standard for usernames. I pointed you to some info someone wrote in the relevant issue on Github regarding what POSIX asserts usernames should conform to, with POSIX being generally accepted to be a standard for *nix type OS's. Your response appears to boil down to "But POSIX doesn't count because not all distro's are POSIX certified"

POSIX counts, for POSIX systems. There is no standard for systemd supported systems. The logic is straightforward, like the reality.

> yes, it's a feature that we don't permit invalid user names(...) So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but still: the username is clearly not valid.

> systemd is not the one coming up with the restrictions on user names, and while some distributions are less restrictive, many do enforce the same restrictions as we do. In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible.

These are pretty clear "refuse to fix". Though I do agree that this is a poor example to illustrate the point.

Reply on news.ycombinator.com