systemd

The second big problem: Attack Surface

On a hardened system without systemd, you have at most one root-privileged process with any exposed surface: sshd. Everything else is either running as unprivileged users or does not have any channel for providing it input except local input from root. Using systemd then more than doubles the attack surface.

This increased and unreasonable risk is not inherent to systemd's goal of fixing legacy init. However it is inherent to the systemd design philosophy of putting everything into the init process.

RED HAT PAYING DEBIAN TO FORCE SYSTEMD

Systemd is not an init system!!
If someone characterizes systemd as an “init system,” you may safely assume that s/he is either utterly clueless or deliberately obfuscating the discussion. Calling systemd an init system is like calling an automobile a cup holder. Not even Lennart Poettering pretends that systemd is anything but the “Core OS” (sic).

What systemd is is an effort to re-create large portions of existing userspace (including login, job scheduling, and networking, just to name a few) inside a single process traditionally reserved for the sole purpose of starting *nix userspace. (Just in case it isn't clear, there is a huge difference between starting userspace (init) and being userspace (systemd).)

At the end of the day, how one perceives this re-creation of existing userspace strongly influences one's reaction to systemd. There are plenty of perfectly legitimate reasons to be troubled by this re-invention of the wheel; they range from the philosophical and aesthetic, to the technical and mechanical, even the purely political and brutally practical.

And that's part of the problem when folks start to “debate” systemd. Very few folks have the chops to think about, much less talk about all of these areas simultaneously. As a result, the discussion becomes fractured and disjointed, in what is literally the textbook definition of bikeshedding. Suddenly, a talking head who's never written a line of code in his/her life offers up an authoritative-sounding-but-utterly-bogus opinion on systemd's maintainability. Add in the fact that folks on both sides (including Poettering himself) act as if name-calling is a perfectly good substitute for empirical evidence, and the “debate” becomes indistinguishable from white noise.

Full story:
http://forums.debian.net/viewtopic.php?f=20&t=120652&p=570371

Linus Torvalds bashing systemd developers for making kernel developers work around their problems

mailing message:

>Key, 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.

>Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.

>This has been going on for *years*, and doesn't seem to be getting any better. This is relevant to you because I have seen you talk about the kdbus patches, and this is a heads-up that you need to keep them separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers.

>But I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project. Because I am *not* willing to take patches from people who don't clean up after their problems, and don't admit that it's their problem to fix.

>Kay - one more time: you caused the problem, you need to fix it. None of this "I can do whatever I want, others have to clean up after me" crap.

http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA

NASA engineer explains why systemd is bad

>My problem with this is that the order in which services are started should, in my opinion, be exactly the same each time and predictable to the sysadmin. With systemd, the order is not deterministic, so you don’t know what’s going to happen next time you boot. I work with servers and embedded devices; I don’t care much about boot time. A server spends several minutes in the BIOS during POST anyway, before the bootloader is even run; making the OS boot faster doesn’t change very much. Embedded devices already start quickly because you trim them down to the bare minimum. What I care about is that every time I boot, the same exact things happen in the same exact order — the order that I want.

>It seems no one can agree on whether systemd is modular or not. I think the problem is with different definitions of ‘modularity’. Systemd doesn’t put everything in PID 1 like some people suggest; it uses modules that communicate with each other. So it is modular in that sense. But these modules are very tightly integrated. You can’t easy remove some of them, or replace them with other things. So in that sense it is very monolithic. This is not at all like having a simple interface and passing data via stdin and stdout, which is the modularity that makes UNIX pipes possible. This is the sense that matters to me.

>[...]I dislike the way systemd is absorbing everything. It’s not just an init system, it’s become an everything-under-the-hood includes-the-kitchen-sink management system. That doesn’t feel modular to me. Why should systemd implement NTP when ntpd already exists? I think systemd-timesyncd and all the others like it are just reinventing the wheel.

Full article: https://bsdmag.org/randy_w_3/

>Systemd is an exploit kit just waiting to be activated. And once it is active, only those who wrote it will be able to defuse it — and check whether it is defused. And it is starting: How to crash systemd in one tweet? Alternatives? Use OpenRC for system services. That’s simple and fast and full-featured with minimal fuss. Use runit for process supervision of user-services and system-services alike.

http://www.draketo.de/light/english/top-5-systemd-troubles

Systemd: The Biggest Fallacies

13 fallacies used by systemd shills to promote the use of systemd:
http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html

TL;DR Install Gentoo and enjoy OpenRC glory

Been using systemd as my init system for about a year now. Works pretty good on my machine.
Thanks, Lennart.

File: 1500477324643.jpg (61KB, 610x345px) Image search: [Google]

61KB, 610x345px

>>61571397
Use void linux becausee runit is comfy as hell

File: 1478396537682.jpg (103KB, 858x536px) Image search: [Google]

103KB, 858x536px

>>61572634
I once Emaild with a problem - he was nice

Every init system is PID 1. All parts of systemd besides the init are unprivileged.

interesting readings, will check if this actually affects me, on a side note lennart looks like an old german granny

>>61571397

sudo kill -9 1

Can somebody tell me why nothing happened?

>>61576177
pid 1 is free to decide what to do