Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Anyways, the bug was trivial to fix, the problem is that it was there in the first place:
it was released and probably used on public accessible machines ("release early, release often") for "all to see".
Who knows how many 0day exploits still lure there?
IMO it's a textbook case of "backdoor injection" to Linux/GNU biosphere (call me a tin hat..)
you will never have bugfree software,
but why this stupid flaming in this case and not in others, kernel, bash, ssl, ... you name it.
oh, it is systemd, we do not go the normal way, report the bug, wait until it is fixed or max ... days, than go public like it is best praxis and common. Oh systemd, lets behave different, ...
so there are 2 problems, a bug in the software, easy to fix, and people behaving not rational, unfixable
what to prefer?
No amount of machismo can save you when a non-threatening command can be used to send the system into a death spiral using even a simple script, command insertion, or other commonly used command interface execution systems.
This isn't a virus, worm, malware, etc. It's just an example of slipshod coding and carelessness of setting limiters on command entries that could prove dangerous.
It's not the fact it can be fixed a4z, it's the fact it does exists at all, and how fast it was found, the fact it can be exploited in a live system, and how long it will take to be fixed, and then how long until distributions pick it up and push out an update or patch.
The key part of that is: "@niedbalski niedbalski committed with keszybz 13 hours ago"
It was fixed well after the article was published... And the fix itself speaks volumes about the mind-blowingly stupid design of this thing.
Quote:
Originally Posted by a4z
you will never have bugfree software
The bugs aren't the issue. The fundamentally flawed design in combination with the attitude of the developer constitute the biggest part of this problem.
Anyways, the bug was trivial to fix, the problem is that it was there in the first place:
Nah, bugs creep into things. The problem is the design itself: the assimilation of system components and especially the dbusification of system service interfaces. A little incompetence in implementation pales in comparison to the threat these present.
Anyway, until such a time as applications foolishly start relying on these dbusified services, Richard is quite correct: Paint it pink and surround it with an S.E.P. field. Having said that, taking the "Problems of others are not our concern..." line has the tendency to come back and bite you in the future.
On the whole I find myself in agreement with the gist of the article, but that's really no surprise and the underlying points raised are not in themselves new.
The key part of that is: "@niedbalski niedbalski committed with keszybz 13 hours ago"
It was fixed well after the article was published... And the fix itself speaks volumes about the mind-blowingly stupid design of this thing.
The bugs aren't the issue. The fundamentally flawed design in combination with the attitude of the developer constitute the biggest part of this problem.
Interesting that a new separate Github issue created to fix the bug in. It's almost as if the cabal are too embarrassed to face up to the error.
Anyway, there is no need to troll anybody any more about this, because moot himself has spoken.
Edit: And now, naturally enough, moot's comment, which was iirc the simple words "way to go systemd", has been deleted. Nothing to see, never happened.
The key part of that is: "@niedbalski niedbalski committed with keszybz 13 hours ago"
It was fixed well after the article was published... And the fix itself speaks volumes about the mind-blowingly stupid design of this thing.
The bugs aren't the issue. The fundamentally flawed design in combination with the attitude of the developer constitute the biggest part of this problem.
what a bad attitude of the developers, fixing a bug after it was reported, not before! 12h after the issue was submitted, what a scandal!
you, with your attitude, would fix the bug before it even was written, wouldn't you? mind-blowingly
and exactly what mind-blowingly stupid is may everyone decide for him/her self.
You, for example, might find you post brilliant, while I think pointing at a bug that got a fix submitted in 12h and talking about developer attitude is mind-blowingly.
you, with your attitude, would fix the bug before it even was written, wouldn't you?
*Yes*
What part of "fail safe" do you not understand?
Edit: Let's repeat montagdude's post #9, which answered your post before it even was written:
Quote:
Originally Posted by montagdude
The purpose of the article was not to point out that there are bugs, but to explain that the design makes these (or any) bugs potentially very critical. Good software would be designed such that any failures would be as isolated from the rest of the system and limited in scope as possible, but systemd is designed in exactly the opposite way. You should just read it, because the author explained that much better than I could.
Uh oh. System does not work perfectly, as I stated initially. Becoming root using su - suddenly takes ages, and systemctl poweroff just times out. This looks indeed like a nasty systemd bug, where any normal user can bring the whole system down on its knees.
what a bad attitude of the developers, fixing a bug after it was reported, not before! 12h after the issue was submitted, what a scandal!
you, with your attitude, would fix the bug before it even was written, wouldn't you? mind-blowingly
and exactly what mind-blowingly stupid is may everyone decide for him/her self.
You, for example, might find you post brilliant, while I think pointing at a bug that got a fix submitted in 12h and talking about developer attitude is mind-blowingly.
Your English is difficult to parse even when you aren't upset; I really don't see why you have an emotional response to people pointing out errors and flaws in systemd. Are you married to it or something?
In any event, there are things called unit tests and code coverage metrics that are used in professional software development environments to catch such issues before they hit the field. I'll point out that the RedHat team that writes systemd is supposed to consist of software professionals (they are paid to write that stuff, aren't they?).
We can also talk about use cases and other ways to ensure that you've covered the various possibilities.
What I find astonishing about this particular bug was that it was triggered by the most obvious edge case of them all: empty input. I'll also add that since it was non-deterministic how many times that you had to write the empty input to provoke the failure, then there is an implication of some deeper issue with the handling of data between and during requests (normally around thread access of some shared data structure).
I've been writing software since 1976 and have been paid to do it since 1995. An error like this would be easy to imagine making it to the field in the 1980's. The world of software practices and testing have come a long way since then.
I'm not sure what this has to do with Slackware at the present moment. If Slackware ever goes systemd a couple of decades from now I hope all severe bugs are worked out by then. I'm curious what Google will use with Fuchsia and Magenta (the linux killer?).
I'm also not sure why there is a heated argument regarding systemd's efficacy? If half of the internet goes down we will know systemd has a problem.
Last edited by RadicalDreamer; 09-29-2016 at 02:01 PM.
"Lie" has a specific meaning. Reconsider your choice of words.
ok, what about: you made a somehow for some funny comment but it was provable not the truth.
is this better?
thanks for the English election, as a non native English speaker I appreciate help with the English language
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.