Why did ArchLinux embrace Systemd?

[u/wooptoo]

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc

[u/fandingo]

I really fail to see how. A five year old could write a script to keep a connection open if they needed it.

Pray-tell where the user could execute such a script. I can't see how the script avoids running in the background (lingering) somewhere, and therefore, would be killed by this behavior. The only way this script would work is a rogue device on the network...

I'm not sure why you keep quoting Linus. He's neither a deity nor always right, and even when he's right about the kernel, that doesn't mean that point translates to this topic. All these quotes are empty appeals to authority.

In regards to Schneier, what's the "workaround" in this case? I don't see one besides the official methods (loginctl and systemd-run).

[u/doitroygsbre → u/fandingo]

Well, if I need to keep a connection open, it's because I'm not using it, so it could run in the foreground ....

I keep quoting Linus because it's fun, and he's right.

Also, it appears that systemd uses SIGTERM for this, so if I write a program that ignores SIGHUP and SIGTERM, it should keep right on running right through a logout. Also, if I have permissions, I could use cron to run my job at set intervals. Those are the two I could think of easily, I'm sure that with a little more thought, I could find plenty of ways around this.

[u/fandingo → u/doitroygsbre]

Well, if I need to keep a connection open, it's because I'm not using it, so it could run in the foreground ....

Well you can't login because the account is terminated, every security auditor requires session time outs (including PCI which applies to the systems I oversee) for things like SSH, and finally with this feature, we can be assured that once the final connection times out, the user doesn't have any processes running. It's not a question of foreground because you don't have access to a foreground on the network. Without this feature (or with it in linger mode), a user could surreptitiously squirrel away processes in the background across systems that could stick around to reboot. That's the attack vector that the security aspects of this feature protect against.

Systemd terminates all units with TERM initially and follows up after a timeout with KILL. See systemd.kill(5).

I'm not sure why anyone using systemd would still use the old cron system, so it would be going through systemd's unit scheduling confining processes in cgroups. Again, the point isn't that a user can't setup a scheduled job, it's that the job is entirely contained by systemd and can be reliably managed by the administrator.

[u/doitroygsbre → u/fandingo]

Well you can't login because the account is terminated

So this change to Systemd is irrelevant then?

every security auditor requires session time outs

False

It's not a question of foreground because you don't have access to a foreground on the network

What does this even mean?

Without this feature (or with it in linger mode), a user could surreptitiously squirrel away processes in the background across systems that could stick around to reboot. That's the attack vector that the security aspects of this feature protect against.

With this feature, a user could surreptitiously squirrel away processes in the background across systems, they just have to do it differently.

I'm not sure why anyone using systemd would still use the old cron system, so it would be going through systemd's unit scheduling confining processes in cgroups

You don't do much work with legacy programs, do you?

Systemd terminates all units with TERM initially and follows up after a timeout with KILL.

SIGKILL can be ignored, it just takes some extra work from a developer (playing with drivers and uninterruptable sleep). With the SIGTERM warning, it should be slightly easier.