[1]Christian Rebischke
[2]About [3]Contact [4]Posts
(BUTTON) (BUTTON)
* [5]About
* [6]Contact
* [7]Posts
Oct 19, 2016
Why suckless is wrong
Many people pointed me to this website [8]suckless when a discussion
about systemd began. Now I got tired of summarizing why this blogpost
is so wrong over and over again. This time I want to write it down that
other people have arguments when they got pointed to this website. This
can take a while so feel free to grab a coffee or a cold mate.
Let us begin with the second abstract:
What PID 1 Should Do
When your system boots up the kernel is executing a given binary in its
known namespace. To see what are the only tasks the application running
as pid 1 has to do, see sinit. Just wait for child process to reap and
run some other init scripts.
First of all: systemd was never, is not and will never be an init
system. It is a system-daemon. Thats why it’s called systemd. Moreover
we don’t live in 1980 anymore. The view and the purpose of computers
had changed completely since this time. We want to have access on logs
in pre-early-boot-time and we want to be sure that several things are
done during the boot process. Computers are not just a server in some
university anymore. Many people use GNU/Linux in their workstations or
notebooks nowadays.
systemd does {,U}EFI bootload
Should systemd’s PID be changed from 1 to a negative, or imaginary,
number? It now exists before the kernel itself, during a bootup. See
also systemd-boot.
Again. systemd is not only an init system. Is the same as if I said:
Should grub’s PID be changed from 4235 to a negative, or imaginary,
number? It Now exists before the kernel itself, during a bootup. See
also syslinux
As you see this sentence is absolutly ridiculous. Systemd has a module
and this module is managing the EFI entries in the EFI bootloader.
systemd-boot is not booting the system. It is just a boot-manager! EFI
does!
systemd replaces sudo and su
Please note the command name, machinectl and its features at the
manpage. In exchange for a program which contains sudo, su and kill
(and does some functions which historically ssh/telnet did), bare metal
users have a tons of bloat and a lot of things to disable, if even
possible, useful only to people which deal with virtual machines.
First of all: systemd-machined or better machinectl will never replace
sudo or su. Do not worry. Secondly machinectl is totally different than
sudo or su. machinectl gets its information from polkit via dbus.
polkit is a much nicer way to define permissions-rules. sudo and su has
different weak points, one of them is that sudo and su can not talk via
dbus nor any other IPC daemon. I think you know this moment when you
forgot to type sudo in front of a command. With polkit you don’t have
this situation because the system service will just ask for a
permission via IPC. And yes.. you will need this for some stronger
security policies than just kernel-based permissions. You can find more
about this topic here: [9]why-polkit
systemd-journald can do log-rotate
Being journal files binaries written with easily corruptable
transactions, does this feature make the log unreadable at times?
Nope. Sorry. It will not get unreadable. I am running systemd now for
years and I had never an unreadable log.
Transient units
Temporary services, because we love to reinvent procps, forking, nohup
and lsof.
What is so wrong with this feature? I think it is a good idea when an
Administrator can pass environment-variables to a service or set
security features via kernel capabilities.
systemd does socat/netcat
This feature is being used in the socket-activation. Something that is
pretty awesome. Why do you want socket-activation? Think about the boot
process. Let us say we start different services at the same time in
parallel. (This is what systemd does because it is increasing the speed
a lot. What is nicer than a laptop that boots up in 0.5 seconds?). When
we start different services in parallel it can happen that a service is
for example earlier ready when the log daemon. In this case socket
activation rescues your day. Because with socket activation the other
service does not need to wait for the log daemon. Every output from
this service will be buffered in the activated socket and will be
forwarded to the log daemon when the log daemon is ready.
systemd-logind does sighup and nohup
Logout is equivalent to shutting off the machine, so you will NOT have
any running program after logout, unless you inform your init system.
Why should it be the other way around? When a user logs out from a
session I want that every process by this user is killed. Especially
the gnome desktop had the problem that even after logouts zombie
processes survived or other artifacts that burn your ram. You do not
realize this on your single-user-system but ask someone who is managing
infrastructure for thousands of users. You don’t want to waste any
memory. And even when we say:
Ok! Let us do your way
We will have one problem. We will allow every program to survive a user
session. You have to see it out of the blacklist-whitelist-view. What
is better a whitelist or a blacklist? When I have 1000 of programs
should I whitelist everyone and blacklist just a few? What happens when
I forgot to blacklist one? Can I blacklist all programs on this planets
via picking every program and analyzing it? No, I can’t and thats why
we use a blacklist and whitelist the programs that are allowed to stay
running after logout. This way we can make sure that only these
whitelisted programs will run and not other stuff like malware, zombie
processes or the 16-years-old users porn torrents.
systemd-nspawn can patch at will any kind of file in a container
Paired with transient units and user escalation performable remotely,
this can mean that if you house VPS instances somewhere, your hosting
provider has means and tools to spy, modify, delete any kind of content
you store there. Encrypt everything, read your TOS.
First of all when I host stuff remotely there is no guarantee that it’s
not bugged even with disk-encryption. Even with disk-encryption the guy
with hardware access could do harmful things and modify, delete, spy
your stuff. This feature is necessary if we want to use namespaces in
containers.
systemd does UNIX nice
Let me quote the first sentence from the README there this feature is
mentioned:
The LimitNICE= setting now optionally takes normal UNIX nice values in
addition to the raw integer limit value.
What is so wrong about when we can limit a nice level for a specific
service? Imagine a service that starts consuming a lot of memory. This
way we can limit this service when it happens and give the other
processes a better place in the scheduling.
systemd locks down /etc and makes it read-only
This is absolutly out of context. systemd uses a capability that is
called ProtectSystem with this capability I can reduce the access for a
specific service that doesn’t need access to specific areas. This means
for /etc that /etc will be mounted read-only. But only for this
service. This way the service is not able to change configuration files
maliciously or unintentionally. I think this is a good feature to
secure your system.
systemd now does your DNS
We are not in North-Korea. DNS is something important nowadays that
every system that wants to do networking need. It was just an amount of
time that this will be included. Moreover you can turn that function
off and still use every other DNS service that you like. It’s also
important for the nspawn-containers. They rely on a proper DNS service.
And mostly: The systemd developers can finally enforce DNSSEC
everywhere with this option. That’s a good step to a more secure
internet.
systemd hates when you adapt your system (graphics on other than vt1)
Support has borders. You can’t support everything in a software and
standards are needed. The internet relies on standards because
standards make the world easy.
__________________________________________________________________
1358 Words
2016-10-19 12:13 +0000
Table of Contents
* [10]What PID 1 Should Do
* [11]systemd does {,U}EFI bootload
* [12]systemd replaces sudo and su
* [13]systemd-journald can do log-rotate
* [14]Transient units
* [15]systemd does socat/netcat
* [16]systemd-logind does sighup and nohup
* [17]systemd-nspawn can patch at will any kind of file in a
container
* [18]systemd does UNIX nice
* [19]systemd locks down /etc and makes it read-only
* [20]systemd now does your DNS
* [21]systemd hates when you adapt your system (graphics on other
than vt1)
[22] Newer
Hackover 2016 [23]Older
The raise of Javascript-droppers
© 2020 [24]Christian Rebischke · [25]CC BY-NC 4.0
Made with [26]Hugo · Theme [27]Hermit ·
References
Visible links
1.
https://shibumi.dev/
2.
https://shibumi.dev/about/
3.
https://shibumi.dev/contact/
4.
https://shibumi.dev/posts/
5.
https://shibumi.dev/about/
6.
https://shibumi.dev/contact/
7.
https://shibumi.dev/posts/
8.
http://suckless.org/sucks/systemd
9.
https://www.collabora.com/about-us/blog/2015/06/08/why-polkit-(or,-how-to-mount-a-disk-on-modern-linux)
10.
https://shibumi.dev/posts/why-suckless-is-wrong/#what-pid-1-should-do
11.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-does-uefi-bootload
12.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-replaces-sudo-and-su
13.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-journald-can-do-log-rotate
14.
https://shibumi.dev/posts/why-suckless-is-wrong/#transient-units
15.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-does-socatnetcat
16.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-logind-does-sighup-and-nohup
17.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-nspawn-can-patch-at-will-any-kind-of-file-in-a-container
18.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-does-unix-nice
19.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-locks-down-etc-and-makes-it-read-only
20.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-now-does-your-dns
21.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-hates-when-you-adapt-your-system-graphics-on-other-than-vt1
22.
https://shibumi.dev/posts/hackover-2016/
23.
https://shibumi.dev/posts/raise-of-the-javascript-droppers-part-1/
24.
https://shibumi.dev/
25.
https://creativecommons.org/licenses/by-nc/4.0/
26.
https://gohugo.io/
27.
https://github.com/Track3/hermit
Hidden links:
29.
https://twitter.com/sh1bumi
30. mailto:
[email protected]
31.
https://github.com/shibumi
32.
https://linkedin.com/in/shibumi
33.
https://shibumi.dev/posts/why-suckless-is-wrong/#what-pid-1-should-do
34.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-does-uefi-bootload
35.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-replaces-sudo-and-su
36.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-journald-can-do-log-rotate
37.
https://shibumi.dev/posts/why-suckless-is-wrong/#transient-units
38.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-does-socatnetcat
39.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-logind-does-sighup-and-nohup
40.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-nspawn-can-patch-at-will-any-kind-of-file-in-a-container
41.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-does-unix-nice
42.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-locks-down-etc-and-makes-it-read-only
43.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-now-does-your-dns
44.
https://shibumi.dev/posts/why-suckless-is-wrong/#systemd-hates-when-you-adapt-your-system-graphics-on-other-than-vt1
45.
https://shibumi.dev/posts/index.xml
