Leaving efi writable like this by default strikes me as a very poor and unsubstantiated design decision.
Leaving efi writable like this by default strikes me as a very poor and unsubstantiated design decision.
Yes, except that none of the tools in question have any support for doing that and so mounting the filesystem read-only rather than read/write would break them. And congratulations, now you've still got a window where something can still break everything while the filesystem is mounted read/write (what happens if the tool crashes during that phase?).
> Leaving efi writable like this by default strikes me as a very poor and unsubstantiated design decision.
Yes with hindsight that's entirely accurate and it was also my decision and nothing to do with systemd.
I agree, but I'm also sure you would agree that a small window were things can go horribly wrong is much more preferable than than a perpetually open one (sudo and friends stand testament to this).
Please bear in mind that my comments are in no way an attack on your person or one directed at systemd. What I want is to find a workable solution or, at the very least, a compromise to prevent this type of issues from occurring. I strongly believe that protecting hardware is a core responsibility of any operating system.
Would it be reasonable for me to ask you to coordinate with all the major tool developers to gradually phasing out this behavior? As in both the filesystem and tooling continue to support both current semantics and a newer version until the older semantics can be safely disabled. This is how support tends to get phased out from the kernel for obsolete hardware.
Issues of this type have reared their heads many times already and I expect they will continue to occur if the underlying reason is not addressed. As the person who has the ability to do something about it, I urge you to reconsider.
What's even more preferable is a situation where the kernel doesn't let you do the damage in the first place, which is what we have now.
All 4 of the tools (that can even be wrapped in a shell script until they are, as systemd devs say, "fixed").
>And congratulations, now you've still got a window where something can still break everything while the filesystem is mounted read/write (what happens if the tool crashes during that phase?).
Better to open a window in the morning then to tear down the whole wall forever.