Alternatively, if, like he says in the comments of that bug, he really means that SystemD shouldn't support systems that allow such usernames, then he should ensure SystemD won't run on such systems.
Silently doing the wrong thing is not a good thing, especially when "doing the wrong thing" is running stuff as root that wasn't supposed to run as root.
> 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.
"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."
And that's basically the problem. Not that the bug exists. But the systemd author doesn't recognize it as such, and refuses to fix it. This seems to be a recurring theme with systemd.
> 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.
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.
> PulseAudio doesn't code defensively against those kind of bugs.
That's a reoccurring pattern across Lennart software. He gets an idea of the way things should work, maybe from the spec or maybe just from his own subjective biases, and has his software expect things to work that way and fail when it doesn't. Every time, he'll say it's the other guys fault. Sometimes his software even fails unsafe and he still blames everybody else.
The '0day' username bug in systemd exemplifies this. Lennart decided that usernames beginning with numbers weren't valid, even though Linux permits it. Systemd was found to run service files with User=0day specified as root instead, not as the user 0day. To Lennart this was not a bug because in his subjective opinion the rest of the system was in error for permitting a username beginning with a number. Even if he were right that usernames beginning with numbers shouldn't be valid, the mere fact that they can occur is reason enough to code defensively around it. At the very least systemd could fail safe when it encounters such an 'invalid' username. But no, he thought there was nothing wrong with failing-to-root. It was everybody else's fault, of course.
> The fact the software doesn't do what any sensible user would expect is completely irrelevant to Poettering.
Logs and error and continues? I think you're confused by Systemd exposing all sorts of frailties of traditional software. How do you propose that it differentiate between UIDs and user names?
The worst is when the rule they cite isn't a real rule at all, like Lennart Poettering's defense of systemd breaking on usernames starting with a digit, which is completely valid as far as the Linux kernel is concerned but he decided such names were ackshully against the rules and therefore systemd wasn't broken, bug report closed not-a-bug.
Are you reading the same thread as me? He replied explaining precisely why this is an error and received nothing but hate for it, 40 thumbs downs.
No, apparently I'm not. In the thread I read, OP mentioned a regex that he found somewhere on the internet, and poettering just confirms it would be invalid. No references who says it's invalid or where to look up the definition. Nothing. Also no mention of the "default to root" issue in his post, which clearly could be considered a security issue as mentioned in several comments on the issue and here in the comments. He says config options are validated to prevent mistakes, but doesn't give any insight why anyone would consider default to root a sane fallback. You call that "explaining precisely"?
On the other hand, you come here to uselessly complain and have the temerity to complain that poettering doesn't write exactly the code you want him to write.
I gave examples of his contradictory behaviour regarding usability and dangerous pitfalls while claiming systemd would be elegant and easy to use. I'm not complaining he doesn't write code I want, I'm complaining he doesn't practice what he preaches and--as stated by the very first phrase of my comment--to explain why it doesn't come as much of a surprise to me he gets so much hate.
I've been working with systemd since late 2012 and like a lot of its ideas and concepts, but the way this guy deals with bug reports and people is just horrible.
That says nothing about why the systemd folks are entitled to hijacking a kernel flag instead of (more sanely) namespacing their own debug flag, which is the actual bug that was filed (and in turn met with "it's not a bug it's a feature, so go whine to the kernel folks about the thing of theirs that we broke and don't feel like fixing", as if the systemd folks have become one with the Microsoft).
Whether or not there are other underlying issues stemming from such misbehavior is irrelevant to the fact that the misbehavior exists. It's like sticking your hand in a fire, then blaming your hand instead of your own stupidity for your third-degree burns.
> it has no business doing random tampering like intercepting logins and DNS requests and renaming device nodes
I agree with the resolving DNS requests complaint, wasn't aware of that to be honest. That actually does seem somewhat odd.
However the other two make sense, systemd is used to init your system. Supporting login functionality as well as mounting and managing devices through udev (which supports renaming devices, as you said) doesn't seem too odd to me.
> Breaking "nohup foo & logout" is shockingly inappropriate;
Can you explain this to me? I never heard about this and my googlefu isn't returning anything fruitful.
> end users should never ever care how an admin may have booted the system much less have to know how to interact with it!
Unless you have an advanced user running `systemctl --user` or trying to check logs then I highly doubt the average user will need to know which init system you are using. For the most part, if you are just using your computer as a facebook/youtube/netflix machine then you probably don't care about the init system your computer is using (which I suspect describes 75% of users), assuming you even know what an init system is.
> Systemd is architected in a way that has a lot of code running as root
That's just objectively wrong.
systemd uses less privileged accounts for many parts, for example systemd-networkd runs as the systemd-network user.
This is different from the classic UNIX way of running everything as root (ISC DHCP Client, NetworkManager, ifupdown, ... all just run as root).
> Systemd is architected in a way that has a lot of code running as root
What would you want to move to a different user specifically?
Systemd is the first one that actually makes modern security features first-class. Most big services run with NoNewPrivileges set, with specific paths allowed, with PrivateTmp, and a bunch of other features. Then there's DynamicUser and other fun bits.
Not only did systemd make it simpler and more common to run bits as different users, it also makes the root ones more restricted.
Just curious, but what names did I call them? Is using their names not allowed?
I recognize your nick from systemd's forums and IRC channel. Nice to see you here defending your favorite project.
>"systemd runs services as independent users, it solves that!"
It's in a terrible way, too. Not sure it improved but I recall somebody once, at a company I worked at, trying to introduce per-unix-user systemd services (e.g. `graphite` user for running Graphite), and there were some atrocious steps required like `loginctl --enable-linger` and God knows what.
We moved to running everything systemd as root, it's easier (and you can specify which unixuser the actual systemd unit runs at, which is "close enough").
Silently doing the wrong thing is not a good thing, especially when "doing the wrong thing" is running stuff as root that wasn't supposed to run as root.
reply