#3438 Issue open: Overhaul simulation mode implementation

Labels: enhancement, cleanup

jsmeix opened issue at 2025-03-25 13:31:

https://github.com/rear/rear/pull/3436
revealed that current simulation mode implementation
has become somewhat messy over time
so it needs to be overhauled.
This is a bigger task for the future as time permits.

pcahyna commented at 2025-03-25 16:36:

We discovered one problem here: https://github.com/rear/rear/pull/3436#issuecomment-2751858143

Another possible improvement would be to source the init scripts even in simulation mode, but that would make them a bit irregular.

jsmeix commented at 2025-03-26 14:50:

I think the real problem is:
When we call that stuff "simulation mode"
we should avoid as much as possible to execute code
which is not actually needed for the simulation.

In particular we must not execute code
that could (potentially) change the system,
i.e. we must not execute code from the user
but only code that we know inside ReaR.

But for a simulation we need to execute some code
(e.g. the WORKFLOW_... functions definitions).

So the real problem is to carefully and thoroughly
determine what code is actually needed for the simulation.

I think this is a bigger task because it requires
to carefully and thoroughly inspect all code
that is currently executed in simulation mode
whether or not it is actually needed.

For example whether or not it is actually needed
to execute user config files when for the simulation
only a few user config variable values are needed
like BACKUP and OUTPUT which we may only read
from the config files without executing them?

Also it is questionable if we really need to execute
the workflow scripts usr/share/rear/lib/[a-z]*-workflow.sh
(see my exceptional code therein for simulation mode)
when all we need is to know the names of the stages
that a particular workflow runs which we may only read
from the workflow scripts without executing them?

pcahyna commented at 2025-03-26 15:02:

When we call that stuff "simulation mode"
we should avoid as much as possible to execute code
which is not actually needed for the simulation.

In particular we must not execute code
that could (potentially) change the system,
i.e. we must not execute code from the user
but only code that we know inside ReaR.

Is it feasible to run simulation mode as a non-root user in order to use the OS-level protections against changing the system? Then if we happen to execute something that should not be executed in simulation mode, we will at worst see some "Permission denied" in the log.

jsmeix commented at 2025-03-26 15:05:

I think sbin/rear needs at least to start up as root user
to have permissions to read /etc/rear/ config files
and things like that.

But to run a workflow in simulation mode
it may work to switch to a non-root user?

Provided that non-root user is in TRUSTED_OWNERS
because otherwise the 'source' wrapper forbids it
which leads to another question if it is really needed
to 'source' scripts in simulation mode when all what
the simulation mode actually does is to print the script name?

I start to like my 'source' wrapper more and more
because it "by the way" even helps us
to see where we may carelessly execute things
which are not actually needed to be executed.

Correction:

In simulation mode we do not 'source' workflow scripts
because in simulation mode the 'Source' function
only prints the script name.

So to run a workflow in simulation mode
it does not help to switch to a non-root user
because no workflow script gets executed.

pcahyna commented at 2025-03-26 15:51:

I think sbin/rear needs at least to start up as root user
to have permissions to read /etc/rear/ config files
and things like that.

But to run a workflow in simulation mode
it may work to switch to a non-root user?

I would say this is too complicated and if users want to run rear as non-root, they are responsible for ensuring that the configuration files are readable, for which there are many ways (adding ACLs to the files, making them group-readable and adding the user to the root group, or even making them world-readable if they don't contain secrets). We should just not prevent it, which we currently do:
https://github.com/rear/rear/blob/1128f1b616b370e49ac7be7f0ae0fa5ab04bc638/usr/sbin/rear#L378

So to run a workflow in simulation mode
it does not help to switch to a non-root user
because no workflow script gets executed.

non-root user would basically be an additional safeguard.

jsmeix commented at 2025-03-26 16:31:

@pcahyna FYI:
This week and perhaps also next week
(currently I cannot tell how long it takes)
I can no longer work on ReaR because
I have to fix several security bugs in other software...

pcahyna commented at 2025-03-26 17:25:

@jsmeix sure, no problem and thanks for the info,
simulation mode would not be my priority anyway (I am not using it), but perhaps I will try to remove this check for root user and see how far one can get with it.

[Export of Github issue for rear/rear.]