#3434 PR `closed`: New TRUSTED_SOURCING_VIA_DOT for trusted sourcing via '.'¶

Labels: bug, won't fix / can't fix / obsolete

jsmeix opened issue at 2025-03-20 12:00:¶

Type: Bug Fix
Impact: Normal
Reference to related issue (URL):

https://github.com/rear/rear/issues/3259#issuecomment-2730011077

How was this pull request tested?

On a SLES15-SP6 VM "rear mkrescue" plus "rear mkbackuponly"
and then on another VM "rear recover" worked for me
with some artificial sourcing via '.' as a test
in etc/rear/local.conf

OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://192.168.178.66/nfs
REQUIRED_PROGS+=( snapper chattr lsattr )
COPY_AS_IS+=( /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
POST_RECOVERY_SCRIPT=( 'if snapper --no-dbus -r $TARGET_FS_ROOT get-config | grep -q "^QGROUP.*[0-9]/[0-9]" ; then snapper --no-dbus -r $TARGET_FS_ROOT set-config QGROUP= ; snapper --no-dbus -r $TARGET_FS_ROOT setup-quota && echo snapper setup-quota done || echo snapper setup-quota failed ; else echo snapper setup-quota not used ; fi' )
SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="5"
TRUSTED_OWNERS+=( 'johannes' )
TRUSTED_PATHS+=( '/home/johannes/' )
TRUSTED_SOURCING_VIA_DOT+=( /home/johannes/johannes.sh /etc/os-release )
source /home/johannes/johannes.sh && DebugPrint "Sourced /home/johannes/johannes.sh via 'source'" || DebugPrint "Failed to source /home/johannes/johannes.sh via 'source'"
. /home/johannes/johannes.sh && DebugPrint "Sourced /home/johannes/johannes.sh via '.'" || DebugPrint "Failed to source /home/johannes/johannes.sh via '.'"
COPY_AS_IS+=( /home/johannes/johannes.sh )

and also in /home/johannes/johannes.sh

#!/bin/bash
this_file_path=$( readlink -e ${BASH_SOURCE[0]} )
DebugPrint $this_file_path is running as $( id )
DebugPrint "sourcing /etc/os-release via 'source'"
source /etc/os-release && DebugPrint "source /etc/os-release worked" || DebugPrint "source /etc/os-release failed"
DebugPrint "sourcing /etc/os-release via '.'"
. /etc/os-release && DebugPrint ". /etc/os-release worked" || DebugPrint ". /etc/os-release failed"

Description of the changes in this pull request:

Avoid the regression that I described in
https://github.com/rear/rear/issues/3259#issuecomment-2730011077

With https://github.com/rear/rear/pull/3424 merged
there will be regressions when third-party scripts
use '.' for sourcing because currently sourcing via '.'
is always forbidden in ReaR.

This is a regression so it is a bug in ReaR because
'source' is not POSIX compliant because
'.' is the POSIX standard command
so ReaR must not forbid using '.' in any case
but allow it when really needed.

To implement trusted sourcing via '.'
in _framework-setup-and-functions.sh
an additional '.' wrapper function is implemented
to enforce trusted sourcing via '.' for exceptional cases
for files which are specified in TRUSTED_SOURCING_VIA_DOT
plus the needed adaptions in sbin/rear for that and
the TRUSTED_SOURCING_VIA_DOT description in default.conf

jsmeix commented at 2025-03-20 12:03:¶

I will do some more testing today and tomorrow
as needed and as time permits.

jsmeix commented at 2025-03-20 14:06:¶

I did some more tests with various changes for
TRUSTED_OWNERS TRUSTED_PATHS TRUSTED_SOURCING_VIA_DOT
and all worked for me as I expect it
(which may not mean very much because I cannot
perform really unexpected tests for my own code).

jsmeix commented at 2025-03-21 07:50:¶

As always sleeping on an issue helps!

The implementation in this pull request is nonsense
because its implementation idea is false because
the idea behind to forbid '.' in general is false.

Reasoning:

Because '.' is the POSIX standard command
POSIX compliant third party software rightfully uses '.'
so ReaR must not enforce an environment where '.' is
forbidden in general.

Assume ReaR calls some tool which has various shell scripts
which use the POSIX compliant '.' (e.g. dracut is such a tool)
then ReaR must not enforce an environment where the user
would have to specify each script that uses '.' to be allowed.

The right solution:

The right solution is a '.' wrapper function which enforces
that '.' is not used in a ReaR script or in a ReaR config file
but which allows '.' in any non-ReaR files.

What ReaR still can enforce is an environment
where all what is executed via 'source' or '.'
is checked to be trustworthy, i.e. for each
file that is executed via 'source' or '.'
its owner must be one of the TRUSTED_OWNERS and
it must be located below one of the TRUSTED_PATHS.

I.e. ReaR can enforce an environment where ReaR
decides what files ReaR will directly or indirectly
execute via 'source' or '.' but ReaR must not
enforce an environment where ReaR decides that
executing via the POSIX compliant '.' is forbidden.

FYI:

I have something in the works (unfinished, barely tested) in my
https://github.com/jsmeix/rear/tree/jsmeix-allow-sourcing-via-dot

More next week...

jsmeix commented at 2025-03-25 09:55:¶

The regression which I described above in
https://github.com/rear/rear/pull/3434#issuecomment-2742598092
should get fixed via
https://github.com/rear/rear/pull/3437

jsmeix commented at 2025-03-25 11:44:¶

This one is obsoleted and superseded by
https://github.com/rear/rear/pull/3437

[Export of Github issue for rear/rear.]

#3434 PR closed: New TRUSTED_SOURCING_VIA_DOT for trusted sourcing via '.'¶