Relax-and-Recover needs real bash and uses 'type -P' to determine program files

[rearuser]

Relax-and-Recover (ReaR) Issue Template

I try to recover a dell bare metal (OS: RHEL 7.8) by rear backup that i did
When i lanch the command "rear recover" it gives me this error:

/bin/rear: /sbin/id : /sbin/ksh: bas interpreter: No such file or directory
ERROR: Relax and recover needs 'root' priveleges (effective user ID is not 0)

and i'am logged with root user

Thank you for your help with this

[jsmeix]

ReaR requires real bash, cf.
#2307 (comment)
and #2322

The interesting part of this issue here is how it could happen
that there is no true bash in the ReaR recovery system?
Cf.
https://github.com/rear/rear/blob/master/usr/share/rear/build/default/990_verify_rootfs.sh#L45

[gozora]

@jsmeix

The interesting part of this issue here is how it could happen

Maybe a symbolic link (/bin/bash -> /sbin/ksh) ?

V.

[jsmeix]

/bin/sh can be a POSIX shell or a symbolic link to a POSIX shell
but /bin/bash must be a real bash (or perhaps a symbolic link to a real bash)
because otherwise #!/bin/bash would not run a script with bash.

[rearuser]

Thank you so much for have taken the time to answer me

Actually i found that this came from the bin/id script
On the server beside the /sbin/id, i have another sbin/id that it used for another purpose under another directory
So i guess that rear when it build the backup instead of taking the /sbin/id of the system it take the last one /DIRECTORY/sbin/id, and this last id file doesn't contain usual binary like /sbin/id
even when i exclude the /DIRECTORY/sbin/id from backup, he still use the same "id" the wrong one
How could i do that rear take the usual id of Redhat OS uder /sbin/id and not the customized one under /DIRECTORY/sbin/id ?

Thank you for your help

[jsmeix]

How programs get copied into the ReaR recovery system
in this case for the example id:

usr/share/rear/conf/GNU/Linux.conf contains (excerpt)

PROGS+=(
...
id
...
)

which gets evaluated in
usr/share/rear/build/GNU/Linux/390_copy_binaries_libraries.sh via (excerpt)

local all_binaries=( $( for bin in "${PROGS[@]}" "${REQUIRED_PROGS[@]}" ; do
                            bin_path="$( get_path "$bin" )"
                            if test -x "$bin_path" ; then
                                echo $bin_path

where get_path is in usr/share/rear/lib/_input-output-functions.sh

# Get the name of the disk file that would be executed.
# In contrast to "type -p" that returns nothing for an alias, builtin, or function,
# "type -P" forces a PATH search for each NAME, even if it is an alias, builtin,
# or function, and returns the name of the disk file that would be executed
# see https://github.com/rear/rear/issues/729
function get_path () {
    type -P $1
}

so what you get in the recovery system for id is
what type -P id results on your system, see
#729 (comment)
for the reasoning behind.

So when you change your system so that type -P id results
a special id binary when root calls type -P id then this special binary
that is your intended one when root calls id will also be used in your recovery system.
This way your recovery system should be consistent with what you have set up
for the user root on your original system.

[jsmeix]

@rearuser
it seems you mix up different things:
The ReaR recovery system versus the backup of your files.
Both are two different and separated things, cf.
#2438 (comment)

[rearuser]

Hello,

Thank you for your feedback
Actually, i find a workaround by changing the $PATH of my environnement to not using the custome bin (/DIRECTORY/sbin), so that type -P get the right path for id binary
i will do a little script to export the PATH variable by deleting the (/DIRECTORY/sbin) and keeping only the "/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:" before lanching the "rear mkbackup"

Thank you for your explanation and help on this topic

[jsmeix]

Only as a side note FYI:
If you changed $PATH for 'root' so that 'root' runs special programs
you probably have messed up how things behave for 'root' by default
and as a consequence arbitrary weird issues appear for 'root'.

If an exceptional program should be run that program needs to be called
with its full path so the special program only runs when actually intended.

FWIW some other scaring examples of same kind:

We at ReaR had noticed that some third party software had set up
some LD_LIBRARY_PATH by default so that all programs used then
the special libraries versions of that third party software which caused
in particular some "interesting effects" for ReaR.

Others had added "foreign" libraries directories to /etc/ld.so.conf
with same kind of "interesting effects" for all normal programs.

We at ReaR had also noticed that some third party software had set up
some special udev rule that changed device names (I think it was the names
of symbolic links to certain kernel devices) so that other programs
did no longer find the devices via the usually expected link names
which also caused "interesting effects" in particular for ReaR.