Hi all,

an occasional rant from you humble almost-lurker.

> From: Rainer Weikusat <rainerweikusat@???>

> In all seriousness, what is the guy supposed to do if some
> less-than-informed person accidentally deletes something he'd better

Let's not lose the point: while stupidly issuing rm -rf / was possibly
intentional (and thus maybe not so stupid, after all) it is quite possible for
some stranded script incorrectly called with root privileges to heavily damage
mounted filesystem (e.g. like a buggy Valve update script, mentioned in recent
messages in various mailing lists, that was trashing / ).

Mistakes (bugs, intrusion attempts) happen all the time despite all means of
prevention that we put in the system. However, the fact that a mechanisms can be
abused is not a valid objection to bad engineering practices.

1) Let's forget for a second that some UEFI implementation is broken.

Why on earth a does a system need to have UEFI variables mounted read-write all
of the time? It exposes those variables to higher risks of corruption.
(You don't keep a root shell with fdisk permanently open in a terminal 24/7,
even if it would ask confirmation before rewriting the partition table, and stil
that would not brick the machine).

Simply put, you don't keep the capability for a dangerous mechanims to change
the system status for longer than it is needed. (Unix) security is built upon
dropping privileges, partitioning capabilities and avoiding the root user as
much as possible. This is standard SW design practice for a number of reasons
that I won't even try to list. You don't keep the gas tank open just because you
don't go around smoking, so to say...

2) Let's face that UEFI is broken on some machines, the implementation does not
follow the standard hence deleting vars can wreak havoc when it should not.

Well, most of the HW designs have quirks that need workarounds to cope with.
Since HW is dealt with by the kernel, the workarounds are within kernel drivers.
This particular quirk is in the firmware of the boot system, which the kernel,
the boot loader AND some user space utilities interact with (that's a loss of
modularity that has been already mentioned). Hence :
( if the workaround is of reasonable complexity, must be there in those places)
OR
( the support for that hardware/firmware has to explicitly be dropped, e.g.
system should not even try to go and start the init process on those machines)

Surprise! Poettering is not doing either choice. He doesn't want to play safe
with marginal hardware and firmware (I omit further polemics here...).

What happens here IMHO is that having the UEFI variables permanently writable is
some design decision of systemd with uspoken reasons (if not simply plain
arrogance to not reconsider one's own design choices and mistakes) and as a
consequence some unspecified portion of the HW is at (small but increased) risk
to be bricked if systemd is allowed to touch it.

We could ask for no better proof of the need to allow init choice, and reason
for Devuan to exist. Of course, we cannot expect that this is ackowledged by
those who don't want to see (further polemics removed...)

Best Regards

    Massimo

-- 
^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^
massimo.coppola@???  coppola@??? www.di.unipi.it/~coppola
Massimo Coppola  -  Tel: +39 (050) 3152992  -  CNR mobile +39 348 3962622
CNR/ISTI "A.Faedo", via G. Moruzzi 1 - 56124 Pisa, Italy        Room C33
-       -       -       -       -       -       -       -       -       -
Eternity is a mere moment, just long enough for a joke.    (H. Hesse)