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

schlomo opened issue at 2024-04-05 16:32:

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 :face_with_head_bandage:. This could lead to an update getting applied to an origin system if somebody would accidentally (or maliciously) run rear recover there.

image

Proposed Solution

Check very early for recovery mode

jsmeix commented at 2024-04-10 07:06:

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 commented at 2024-04-10 13:09:

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

jsmeix commented at 2024-04-10 13:27:

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 commented at 2024-04-10 13:56:

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.

[Export of Github issue for rear/rear.]