Rainer Weikusat <rainerweikusat@???> wrote:

>> Or the third option - mount r/o and remount r/w when needed.
>
> As I wrote in the original text, that's a extremely bad idea because
> this means it may suddenly be affected by an already running command
> never supposed to work with it.

The window for that must be "very small". Yes I know about TOCTOU issues, but unless a command has a long execution time, then it's got to run during "just" the small window between the fs being made r/w and it being made r/o again - typically a few seconds.

Requiring user intervention (ie making it writeable) has just the same problem - except that the window is very much longer. Not to mention, the risk of forgetting to "lock the door" again afterwards.

Just mounting r/w leaves us with the problem as already described.

So IMO, of the options presented, remounting as required would seem (to me) to be the least bad.

One way I could see it being done (and avoiding the need to modify exiting utils) would be to provide a wrapper which :
- remounts as r/w
- runs the command
- remounts as r/o
The wrapper can be made as simple or complicated as wanted - and could, for example, do one of several things :
1) Prompt the user that the fs needs to be remounted r/w and wait for the user to do it
2) Prompt the user that this needs to be done (perhaps with warnings about other stuff accessing the fs), and ask for confirmation before doing it.
3) Have a config option to assume a "yes" response to option 2) - in much the same way as the -y or --force flag on so many utilities.
Option 3) puts the choice in the hands of the admin - it's up to him to set the option, and if the config file is suitably commented then that also deals with the "inform the user of the problem" aspect that no amount of release notes etc will cover.


I think we all agree that as long as there are EFI systems that are broken in this way, then there is no "100% safe" way around it - just varying degrees of "least bad".