#2331 Issue `closed`: Hard-coded home directory of root¶

Labels: enhancement, cleanup, fixed / solved / done

gozora opened issue at 2020-02-07 08:47:¶

ReaR have on multiple places hard-coded home directory of root user. This is OK most of the time, but I've came across multiple servers that had home directory of root user relocated (for various reasons) to different locations (e.g. /root/home/root).
Since ReaR requires to be launched under root user, I think that we should replace static string root/.ssh/* with $HOME/.ssh/* to reflect real home directory of root.

What do you guys think?

If there are no objections I would prepare PR ...

V.

jsmeix commented at 2020-02-07 10:18:¶

I am wondering what the officially right home directory for the root user is.

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
tells

/root    Home directory for the root user.

so on first glance according to plain reading only that piece of text
it seems the "officially right home directory for the root user"
could be indeed hardcoded /root.

On the other hand "Dirty hacks welcome" in
https://github.com/rear/rear/wiki/Coding-Style
reads

it is more important that the Relax-and-Recover code works
than having nice looking clean code that sometimes fails

I fear there are cases (e.g crazy admins or whatever ;-)
where /root exists but for the root user $HOME
is set to a different directory so we cannot make
a hardcoded decision in our code if hardcoded /root
or the root user's $HOME value is the right place.
In this case the usual way out of "*nix diversity hell"
is to have just another config variable in default.conf

# According to the Filesystem Hierarchy Standard
# the home directory for the root user has to be '/root'
# cf. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
# but you may set it as needed like ROOT_HOME_DIR="$HOME"
ROOT_HOME_DIR="/root"

and use its value in our scripts.

jsmeix commented at 2020-02-07 10:30:¶

What scripts I found where a hardcoded /root is used
for the home directory of the root user:

# find usr/sbin/rear usr/share/rear/ -type f \
 | xargs grep '/root' \
 | egrep -v ': *#|TARGET_FS_ROOT/root|/rootfs|ROOTFS_DIR/root|EFI_STUB_EFIBOOTMGR_ARGS|FHSdirectories' \
 | cut -d ':' -f1 | sort -u

usr/share/rear/conf/examples/borg-example.conf
usr/share/rear/lib/global-functions.sh
usr/share/rear/prep/DUPLICITY/default/050_prep_duplicity.sh
usr/share/rear/prep/DUPLICITY/default/200_find_duply_profile.sh
usr/share/rear/rescue/default/500_ssh.sh
usr/share/rear/restore/DUPLICITY/default/110_check_temp_dir_with_duply.sh
usr/share/rear/setup/default/005_ssh_agent_start.sh
usr/share/rear/skel/default/bin/login
usr/share/rear/skel/default/etc/passwd

gozora commented at 2020-02-07 10:31:¶

Hmm, I'd prefer to have ROOT_HOME_DIR=$HOME as default because home is wherever $HOME points to :-), and use "/root" as reasonable fallback when $ROOT_HOME_DIR is empty/unset or non existing.

V.

jsmeix commented at 2020-02-07 10:35:¶

Any reasonable default is o.k. for me
but it should be sufficiently fail-safe e.g. like

test -d "$HOME" && ROOT_HOME_DIR="$HOME" || ROOT_HOME_DIR='/root'

because I think it is not impossible that $HOME migt be unset
or false set at the time when "rear" is run.

jsmeix commented at 2020-02-07 10:37:¶

@gozora
sorry for my weisenheimer comment - I had not read that you
had already described the exact same fallback behaviour.

gozora commented at 2020-02-07 10:38:¶

test -d "$HOME" && ROOT_HOME_DIR="$HOME" || ROOT_HOME_DIR='/root' looks good.

Do you think it could be verbatim used in default.conf

jsmeix commented at 2020-02-07 10:41:¶

Why not?
All config files are sourced and executed as sctipts, cf.
https://github.com/rear/rear/issues/2311
and for an example see
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L87

gozora commented at 2020-02-07 10:42:¶

OK, see you in comments under PR ;-).

Thanks for now!

V.

jsmeix commented at 2020-02-07 10:55:¶

I promise to refrain from "by the way while you are at it" ideas
in your upcoming pull request (at least this time ;-)

gozora commented at 2020-02-07 11:30:¶

@jsmeix you don't need to! If something has to be fixed, then it has to be fixed ;-)

V.

jsmeix commented at 2020-02-07 11:54:¶

No worries!
Deliberately I had only promised for "at least this time" ;-))

pcahyna commented at 2020-02-07 13:21:¶

I would say the usual idiom is
ROOT_HOME_DIR="${HOME:-/root}"

Also, is the intent to let the user set it? If not, it probably should not be in default.conf because it serves as documentation of what are all the supported user-settable variables.

gozora commented at 2020-02-07 13:28:¶

Hello @pcahyna,

I would say the usual idiom is
ROOT_HOME_DIR="${HOME:-/root}"

That look handy, I'll certainly consider using it.

Also, is the intent to let the user set it?

As far as I know, everything in default.conf can be overridden by local.conf/site.conf.

V.

jsmeix commented at 2020-02-07 13:34:¶

@pcahyna
thank you for the much simpler code.

The intent is that the user could specify ROOT_HOME_DIR
to anything as needed in even special exceptional cases
(cf. "final power to the user") regardless that I assume

ROOT_HOME_DIR="${HOME:-/root}"

does the right thing in 99.999999% of the cases.

pcahyna commented at 2020-02-07 13:46:¶

One possible problem with this approach is if one wants to run ReaR as not-root user (it would have to be a user which is granted some special capabilities). In that case, does one really intend to use the $HOME of that user? If so, this approach is fine. OTOH if one really means the home directory of root, it could be better to use ~root. (Executing as non-root is currently not supported, but should not be prevented in the future.)

IMO it is also necessary to distinguish the original system - where rear mkrescue or rear mkbackup is being executed and where root may have a non-standard $HOME (so this concern is valid), and the rescue ramdisk, which is created by us and we can hardcode /root, because we know where we put it.

gozora commented at 2020-02-07 13:50:¶

I'm intending to change only hard coded values only for original system (where mkbackup or mkrescue) is launched, ReaR recovery system should remain unchanged.

V.

gozora commented at 2020-02-07 13:58:¶

One possible problem with this approach is if one wants to run ReaR as not-root user (it would have to be a user which is granted some special capabilities). In that case, does one really intend to use the $HOME of that user? If so, this approach is fine. OTOH if one really means the home directory of root, it could be better to use ~root. (Executing as non-root is currently not supported, but should not be prevented in the future.)

This is a good point, although I'm not sure if anybody ever tried to launch ReaR just with capabilities, but to be on safe side ~root should be more suitable than $HOME. Even further, how about reading root home directory from /etc/passwd to avoid possible problems with ~root (I'm not sure how fail safe ~root is, despite I'm using it quite often).

V.

pcahyna commented at 2020-02-07 14:09:¶

@gozora this is more a discussion point, in fact $HOME might be entirely appropriate (one might prefer to copy the invoking user's ssh keys instead of root's ssh keys - assuming that recovery will be executed as the same user).

Concerning ~root, if root's home is indeed intended, I think ~root is preferable to parsing of /etc/passwd, the latter seems more error-prone.

gozora commented at 2020-02-07 14:18:¶

I'm looking here for replacing /root/ with actual root home directory so I think that additional complexity with "invoking user" should not be messed with. So let's stick with ~root for now.

V.

pcahyna commented at 2020-02-07 14:24:¶

Makes sense, the transition to $HOME where appropriate can be made separately.

jsmeix commented at 2020-02-07 14:47:¶

I think currently it is totally unsupported to run ReaR as non-root user
like a user with effective user ID 0 that is not named root.
I.e. I would not be surprised if the user name must be root.

But I never even tried to run ReaR as non-root user
except by accident where I was exited at
https://github.com/rear/rear/blob/master/usr/sbin/rear#L288

# ReaR must run as 'root' (i.e. abort if effective user ID is not 0):
if test "$( id --user )" != "0" ; then
    echo "ERROR: $PRODUCT needs 'root' privileges (effective user ID is not 0)" >&2
    exit 1
fi

gozora commented at 2020-02-07 14:52:¶

@jsmeix maybe one day, when there is nothing more to fix, we can take a look into thins :-).

V.

jsmeix commented at 2020-02-07 15:11:¶

Yes!
Preferably on a relaxed weekend when nothing else is to do ;-)

Have a nice and relaxed weekend!

jsmeix commented at 2020-02-12 09:07:¶

According to what
http://relax-and-recover.org/documentation/getting-started
reads (excerpts)

git clone https://github.com/rear/rear.git
cd rear/
sudo usr/sbin/rear format /dev/sdb
sudo usr/sbin/rear -v mkrescue
sudo usr/sbin/rear -v mkbackup

it seems ReaR works when a normal user calls it via sudo
which seems to be sufficient at least as far as sudo works
on my openSUSE Leap 15.1 system:

johannes@host:~> sudo bash -c '( set -x ; pwd ; echo $HOME ~root ~ ; id )'
[sudo] password for root:

+ pwd
/home/johannes
+ echo /root /root /root
/root /root /root
+ id
uid=0(root) gid=0(root) groups=0(root)

so it seems sudo behaves more like su root than su - root
but it seems for ReaR sudo and su root are sufficient.

[Export of Github issue for rear/rear.]

#2331 Issue closed: Hard-coded home directory of root¶