Bug: ReaR should abort as early as possible if rear recover is run outside rescue system

[schlomo]

Problem

While working on the #3190 story I noticed that we first apply an update downloaded from $RECOVERY_UPDATE_URL and then check if we are actually in the recovery system 🤕. This could lead to an update getting applied to an origin system if somebody would accidentally (or maliciously) run rear recover there.

Proposed Solution

Check very early for recovery mode

[jsmeix]

init/default/030_update_recovery_system.sh contains

test "$WORKFLOW" != "recover" && return

so I wonder how it could apply an update downloaded
into the original system?

[schlomo]

Yes, still felt wrong to check so late for recovery mode 🤷

[jsmeix]

Of course the check for recovery mode was too late
but I asked because I do not understand your
initial description of this issue which looks
as if you got update downloaded appiled onto
your original system by 030_update_recovery_system.sh
i.e. as if I made a severe bug in that script.

FYI about its history:

# git log -p --follow usr/share/rear/init/default/050_check_rear_recover_mode.sh

shows at its end i.e. at the very beginning of time
(excerpts):

commit d8f1571a213a9df272327bb070e8a87f78fc14c3
Author: Johannes Meixner <jsmeix@suse.com>
Date:   Thu Oct 27 12:44:16 2016 +0200

    renumbered by ading a trailing 0 so that 12 becomes 120
    except 00 which becomes 005 and adapted symlinks to point
    again to the right re-numbered scripts
...
rename from usr/share/rear/init/default/05_check_rear-recover_mode.sh
rename to usr/share/rear/init/default/050_check_rear-recover_mode.sh

commit ad2283c402736253e4f76d36659f353695aeceea
Author: Gratien D'haese <gratien.dhaese@gmail.com>
Date:   Fri Dec 11 18:14:31 2015 +0100

    prevent any other workflow in REAR rescue mode
    then recover - see issue #719
...
--- /dev/null
+++ b/usr/share/rear/init/default/05_check_rear-recover_mode.sh

so 05_check_rear-recover_mode.sh
(relatively early in 00...99)
became 050_check_rear-recover_mode.sh
(relatively same early in 000...999).

So my fault was to add 030_update_recovery_system.sh
before 050_check_rear-recover_mode.sh
so I needed the extra check
instead of after it and then leave out the check.

[schlomo]

Ah, so I sort of fixed what happened at that old XX to XXX change? Nice.

I didn't have a problem with unplanned system updates, it was more of a thought.