#2311 Issue `closed`: 'rear -s' executes config files¶

Labels: enhancement, documentation, fixed / solved / done

jsmeix opened issue at 2020-01-15 09:53:¶

ReaR version ("/usr/sbin/rear -V"):
current master code
Description of the issue (ideally so that others can reproduce it):

I have in /etc/rear/local.conf

LogPrintError "local.conf gets actually sourced"

and with that e.g. rear -s mkrescue results

# usr/sbin/rear -s mkrescue | head -n20
Relax-and-Recover 2.5 / Git
Running rear mkrescue (PID 27286)
Using log file: /root/rear.github.master/var/log/rear/rear-g243.log
Simulation mode activated, Relax-and-Recover base directory: /root/rear.github.master/usr/share/rear
Source conf/Linux-i386.conf
Source conf/GNU/Linux.conf
Source conf/SUSE_LINUX.conf
local.conf gets actually sourced
Source init/default/005_verify_os_conf.sh
...

The reason is in the Source function

    # Clip leading standard path to rear files (usually /usr/share/rear/):
    local relname="${source_file##$SHARE_DIR/}"
    # Simulate sourcing the scripts in $SHARE_DIR
    if test "$SIMULATE" && expr "$source_file" : "$SHARE_DIR" >/dev/null; then
        LogPrint "Source $relname"
        return
    fi

so simulation mode applies only for scripts in /usr/share/rear/
but files in other directories get actually sourced i.e. executed.

The bug is that
on the one hand it is perfectly o.k. when the user runs commands
in his config files as needed e.g. to set specific config variables
depending on certain conditions or even to do some needed things
before the actual ReaR scripts are run so that his commands
could actually change something in his running system
but on the other hand simulation mode should neven ever
change something in the user's running system.

The explicit condition expr "$source_file" : "$SHARE_DIR"
indicates there is a reason why simulation mode applies
only for scripts in /usr/share/rear/ but - as usual - there
is no comment that tells about that reason.
That condition originates from the very beginning of Git history
https://github.com/rear/rear/commit/07c0385e931ffad1a79d7ea841a6d3f978f0bea9

jsmeix commented at 2020-01-15 09:55:¶

@schlomo @gdha
do you perhaps know a reason why simulation mode
applies only for scripts in /usr/share/rear/
but not for other sourced files like config files?

gdha commented at 2020-01-17 11:31:¶

@jsmeix Well, Sclomo and I considered the config files as configuration only in 2006 , and we never thought that these files could contain lines of codes that were meant for execution (even as they are treated as bash files).
Of course, times changes lots of things and the scope of ReaR became much wider.
It is not a bug, but rather a design flaw ;-) I would say.

jsmeix commented at 2020-01-17 12:44:¶

@gdha
thank you for the information.

I think I will meditate on it ;-)
and try if I can improve how things behave
as far as possible with reasonable effort
which could mean in the end only some additional
comment that describes the potential issue
in our default etc/rear/local.conf
https://github.com/rear/rear/blob/master/etc/rear/local.conf

jsmeix commented at 2020-01-17 13:40:¶

As a first step I did
https://github.com/rear/rear/commit/6207d1f024f601eae2bc4fb092d17e265cb80d93
so things are now at least documented.

Perhaps I can further improve how things behave
but that happens later as time permits.

Usually commands that are run in config files
should not actually change (i.e. write) something on the system.
Instead such commands should normally only read something
on the system to set set different configuration values depending
on certain conditions (e.g. values of the enviroment where rear runs)
as needed by the user's particular case.

jsmeix commented at 2020-03-06 14:07:¶

I consider it sufficiently "fixed" (i.e. only documented) by
https://github.com/rear/rear/commit/6207d1f024f601eae2bc4fb092d17e265cb80d93

[Export of Github issue for rear/rear.]

#2311 Issue closed: 'rear -s' executes config files¶