Autor: Simon Hobson Fecha: A: dng@lists.dyne.org Asunto: Re: [DNG] Bad UEFI: was Systemd at work: rm -rf EFI
Arnt Karlsen <arnt@???> wrote:
> ..me, I do not see any point in keeping it mounted at all.
> Whenever such a need arises, it should be mounted read-only.
> If a need to write to /sys/firmware/efi/efivars should happen,
> the machine should first be taken off-line, backed-up etc out
> of production and into a maintenance mode, where mounting
> /sys/firmware/efi/efivars read-write, _may_ be warranted.
Yes, in an ideal world where everyone is a "full time admin". But in the real world, more systems are used by "average users" who just expect "stuff to work". So IMO, you either build stuff that works (or at least is up-front about what's wrong), or you leave these people stuck with "stuff that's broken" and regardless of how right you are, the pi**ed off user will be moaning about how "rubbish and complicated this Linux is - best go back to Windows".
Rainer Weikusat <rainerweikusat@???> wrote:
> 'A distribution' would usually provide some default settings for
> mounting virtual filesystems but I don't really care what these are. If
> I don't consider such a filesystem particularly useful, I wouldn't be
> running a kernel supporting it at all and if I did, I'd change the
> defaults to whatever I consider sensible.
That's fair enough, you are clearly in a position to do that. But as per above, the vast majority of users are not.
> I'd be seriously annoyed by some software which would silently remount
> stuff I've chose to mount r/o r/w (and back in the hope it'll never be
> caught red-handed) instead of complaining that blablala can't be done
> because lalala can't be written to.
Which is why I suggested a scheme that stops, prompts the user, and if the user says yes then goes ahead and does it - with an option that the user can set (file in /etc/default with suitable comments ?) that allows those who don't want the prompt every time to tell the system "just do it".
Seems to me, that would provide a working default that a) protects (as far as possible) the UEFI fs, b) puts the user in control of access to it (assuming random sh*t doesn't just go ahead and ignore the users settings).