On Sun, Aug 30, 2020 at 09:25:08PM +1000, Russell Coker wrote:
> One feature of systemd is fast boot, unless it has an error and gets you 90
> second timeouts etc.

It can be (and often is) worse than just 90 seconds. I've had both bootups and
shutdowns delayed by 10s of minutes or longer while it retries and retries for
progressively longer times. it's really fucking annoying. and you can't even
hit Ctrl-C or something to force it to abort.

A few times i've let systemd try to shutdown or reboot for HOURS, just out
of curiousity to see if it will ever just give up on whatever's failing, and
reboot anyway.  AFAIK it would have gone on retrying forever if i hadn't
power-cycled it.


also, i don't reboot very often (on average, every two months or so. or even
less often - e.g while my desktop machines got kernel upgrades about a week
ago to 5.7.0-2-amd64 from debian sid, my main server/gateway box was last
rebooted 201 days ago and is still running 5.3.0-3-amd64). saving a few
seconds every year is hardly worth writing home about, and is more than offset
by how long it takes to shutdown or reboot (IME that's *always* slower under
systemd, usually by several minutes)


> What I like are the better security features.  One example is terminal
> control.  If you have an init script that launches a daemon under a
> different UID then if that daemon isn't started by runuser or something
> similar then the daemon can push characters into the keyboard buffer of the
> shell.

and if you're running a daemon or something that does that, then you've got
greater problems to worry about - anything that could install a compromised
daemon already has root access and doesn't need access to your keyboard
buffer.

i'm not saying that this kind of separation is worthless, just that it's not
enough by itself.

To start with, don't install packages from untrusted repositories and NEVER
use brawndo-installer, which is a favourite of idiot devs (usually python or
ruby or nodejs devs, but not exclusively) and looks something like this:

    curl URL | sudo bash

or as a function, highlighting all of its "features":

    brawndo() {
       curl $1 | sudo /usr/bin/env bash
    }

> ps axo pid,sess,comm|grep $$
>
> The above command shows processes in the same session group as your shell.

or you could use namespaces and lsns or pgrep --ns

> Now you can modify all scripts to use runuser, but that's going to be a pain.
> systemd does all this for you.

which is nice if you never need to do anything in a way that the systemd devs
didn't think or use themselves. or deliberately disallow. in that situation,
you're fucked.


> Also systemd allows blocking daemons from accessing /home and other security
> features.

no, the kernel does that. systemd just makes use of kernel namespace features.
it's not alone in being able to do that - containerd and docker and firejail
and many other programs make use of namespaces.

> When it does those sorts of things they are in a standard format so you can
> grep service files to make sure that all daemons meet the security goals
> that you have instead of having to read lots of shell scripts written by
> different people for such things.

I really don't get why systemd fans are so terrified of shell scripts.

especially when systemd is so poorly documented. it's not as if systemd unit
files are paragons of clarity, or that there's any easy way to get an overview
of the dependency relationship between units.

craig

--
craig sanders <[email protected]>
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Reply via email to