That is all.
To obtain root privileges on a Linux distribution that utilizes systemd for initialization, start with an invalid user name in the systemd.unit file. Linux usernames are not supposed to begin with numbers, to avoid ambiguity between numeric UIDs and alphanumeric user names. Nevertheless, some modern Linux distributions, like …
This is classic Poettering. "I never make mistakes, if it doesn't work you must be doing something wrong". Too many of the Systemd "team" think the same way.
Does anyone remember this previous el Reg story? https://www.theregister.co.uk/2014/04/05/torvalds_sievers_dust_up/
Here's Linux Torvalds firing a torpedo at Systemd developer Kay Sievers after a Systemd bug made Linux systems unbootable and the Systemd "team" refused to fix it, saying that everyone else had to rewrite their code to work around it because Systemd was perfect:
"Key, [sic] I'm f*cking tired of the fact that you don't fix problems in the code *you* write, so that the kernel then has to work around the problems you cause," Torvalds fumed, adding that he wouldn't merge any more of Sievers' code into the kernel until he cleans up his act.
As we can see, nothing has really changed since that was written in 2014.
OK this guy sounds like the classic "My code is soooo precious" programmer but why do these (and only these) distros do this?
Does systemd do it to be compatible with them?
Under what circumstances is this behavior actually useful?
I can't think of a reason, other than some one cocked up development and others are playing follow-the-leader but is that the case?
It doesn't matter if it's useful or not, it's used in some distributions and systemd should be able to cope with it.
And someone at Red Hat should remind him who he works for and force him to open that bug again and fix it as otherwise it's a potential security problem on their own OS.
I remember trying to get support on the pulse audio mailing list - another of his fine creations, and being told (by Lennart) it was buggy alsa drivers that were at fault, not pulse audio so I should take up my problems with the alsa developement team.
The alsa drivers were obviously fine, the problem was in pulse (admittedly in an early incarnation) but the attitude was already there.
Could Poettering be an MS deep cover agent?
Lemme see... Buggy code with potentially significant security flaws? Check
Horrible attitude towards other? Check
Utter refusal to fix bugs? Check
Arrogant fuckwit who thinks he is God's gift rather than satan's diarrhea? Check
Nah, couldn't possibly be...
You left off the bit where Systemd looks and acts an awful (and I do mean Awful!) lot like the Windows registry; what with binary configuration files and logs that need the program itself to read them.
So if Systemd* crashes, it writes to a binary log, which requires Systemd* to load up to read the logs - What could go wrong?
*or the bits o' windows that read/handle the Registry
"So if Systemd* crashes, it writes to a binary log, which requires Systemd* to load up to read the logs - What could go wrong?"
Now, now... you just need to adapt to the new way of Linux'ing. No need to be critical ;)
It will only be a few months before the Samba stack gets imported into systemd and after that you can easily access those logs right after booting with your trusty Windows 10 environment.
This is a more generic problem in the open source community. People creating things as a hobby who just don't quite 'get' all those older principles us grey hairs used to live by and enterprises, anybody with a connection to the wild internet really, have to live by - like the principle of least privilege, like fail-safe over fail-soft (which may mean not being so forgiving about bad input!), like learning from the mistakes of others rather than continually choosing to repeat them yourself (to be fair this one is much more widespread than the FOSS community) and the list goes on.
implies Poettering is a clueless amateur, I take it. no argument from me!
I particularly dislike the use of 'exceptions' rather than checking return values. It's seems to be worse coming from the Python crowd...
It would be nice to run these clueless amateurs through a 'programming boot camp' where you ONLY get to code in 'C', and you MUST check buffer sizes and return values for things like "the file wasn't opened" and "attempting to overflow the buffer".
(and of course, check that the username is a VALID user name, and don't assume root privs when it's *NOT*)
yeah, I'd have a clue-bat, a clue-by-four, and a cat-5-o-nine-tails ready at all times
Ehm, the rule of law started a little before. Hammurabi could tell something, and the Roman law formed the basis for the rule of law in Europe.
Universal human rights are a product of Enlightenment, medieval people and religions were fully satisfied with slavery, castes, sentencing free thinkers, etc. etc.
"Universal human rights are a product of Enlightenment"
Magna carta (1215) made such a good start at this that it took about 800 years before May managed to remove the concept of due process. The presumption of innocence didn't actually come from there but was introduced, I think from France, also in medieval times (maybe this is a further reason why May is in favour of Brexit - all these foreigners with inconvenient principles of law).
The presumption of innocence didn't actually come from there but was introduced, I think from France
I had a vague memory France had the opposite under Napolean Code, but a quick DuckDuckGo suggests I had this wrong.
Cool. Learned something new (or rather "corrected erroneous data in my head") :)
No, it's clueless return values which are from a medieval era. The "file was not open". Nice. But why it wasn't opened? Was it an RTL error? Was it an OS error? If it was an OS error, what was the original OS error? Do I have a chance to retry it, or not?
The issue with simple return values is they are "monodimensional" and may lose information along the way.
My best practice is "if you can add information to an error, but never remove from". So if a deeply nested routine encounters an OS I/O error, for example, it needs to pass this error to its callers, which may add more information, to allow the higher level one understand what it could do with the error.
Isn't not checking and acting properly on return values part of this very bug?
Yeah, I'm going to consider this a bad user ID so I'm not going to change to it, I'll carry on as root as I can't stop as I'm booting the system, so I'll just stick a warning in the log and hope that somebody reads it.
Later when somebody files a bug report...
ITS THERE BAD SOFTWARE!!!!11!11!1
I mean he works for the same employer that makes Red Hat (which considers it a good user ID), FFS.
The lack of exceptions if one of the reasons that makes C code so fragile and vulnerable. Even after you checked return codes you may have issue properly handling (i.e. freeing resources) and propagating errors without exceptions, usually needing a lot more fragile code and hacks (like gotos).
A small error, and code will keep on happily running in an unstable state, often creating exploitable vulnerabilities. There is also the need to propagate error information, with in C requires to use some static data somewhere, and additional "geterror" calls, hoping they were made thread-safe.
C++ didn't address the issue fully because of its obsession for RAII (which lead to the need of smartpointers - another hack needed to solve a design issue, but not everybody understands and use them properly). That's why we see lots of vulnerabilities around in C/C++ code.
Then there are many ways to use exceptions the wrong way as well.
But it's only amateurs that believe C is the perfect language, and it was creates as such.
Biting the hand that feeds IT © 1998–2019