#3627 PR merged: Set TRUSTED_FILES 'readonly' after sourcing config files

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2026-08-06 14:40:

  • Type: Enhancement

  • Impact: Security

Not setting TRUSTED_FILES 'readonly' would be a security issue.

  • Reference to related issue (URL):

A follow up of https://github.com/rear/rear/pull/3621

  • How was this pull request tested?

Tested same as in
https://github.com/rear/rear/pull/3621#issuecomment-5179082263

  • Description of the changes in this pull request:

Set TRUSTED_FILES 'readonly' after the
user config files were sourced.

Additionally
rename the function 'is_writable_only_by_owner' into
'is_trusted_write' (abbreviation for 'is_trusted_write_permissions')
so all functions for trust checking
have the same prefix 'is_trusted_'.

Also added a convenience function 'is_trusted'
to call the trust checking functions all together, see
https://github.com/rear/rear/issues/3260#issuecomment-5204202527

codacy-production commented at 2026-08-06 14:41:

Up to standards ✅

🟢 Issues 0 issues >
> > **Results:** > `0` new issues > > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3627/issues) >

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

jsmeix commented at 2026-08-06 15:39:

@rear/contributors
provided there are no severe objections
I would like to merge this pull request
tomorrow early afternoon.

jsmeix commented at 2026-08-06 15:47:

The current is_trusted() implementation here
is very likely not the final one.

With this pull request I only liked to have some offhanded
initial is_trusted() function to show the basic idea, see
https://github.com/rear/rear/issues/3260#issuecomment-5204202527

As time permits (i.e. as CVEs permit)
I will implement when I am back from vacation
step by step what I wrote in
https://github.com/rear/rear/issues/3260#issuecomment-5204202527
and then I will see what is_trusted() implementation
works reasonably well in practice.

jsmeix commented at 2026-09-18 13:05:

A side note regarding performance:

I was wondering if my current implementation
in _framework-setup-and-functions.sh

function is_trusted_file () {
    ...
    for trusted_file in "${TRUSTED_FILES[@]}" ; do
        test "$actual_file" = "$trusted_file" && return 0
    done
    return 1
}

...

function source () {
    ...
    if ! is_trusted_file "$source_file" ; then
        # Enforce source file owner is trusted:
        is_trusted_owner "$source_file" || Error "..."
        # Enforce source file is at most writable by its owner:
        is_trusted_write "$source_file" || Error "..."
        # Enforce source file starts with a trusted path:
        is_trusted_path "$source_file" || Error "..."
    fi

is still sufficiently performant
even when there are many files in TRUSTED_FILES
because it always calls is_trusted_file()
which iterates over all files in TRUSTED_FILES.

I tested it with artificial files in TRUSTED_FILES
which are never sourced to ensure all those files
get always needlessly tested in is_trusted_file().

With empty TRUSTED_FILES:

# time usr/sbin/rear -v mkrescue
...

real    0m56.726s
user    0m23.122s
sys     0m37.138s

With 100 artificial files in TRUSTED_FILES:

# time usr/sbin/rear -v mkrescue
...

real    0m56.177s
user    0m22.963s
sys     0m36.676s

With 1000 artificial files in TRUSTED_FILES:

# time usr/sbin/rear -v mkrescue
...

real    0m58.827s
user    0m24.044s
sys     0m38.134s

With 10000 artificial files in TRUSTED_FILES:

# time usr/sbin/rear -v mkrescue
...

real    1m9.900s
user    0m31.514s
sys     0m42.192s

So 100 TRUSTED_FILES are unnoticeable,
1000 TRUSTED_FILES make it about 2 seconds slower,
10000 TRUSTED_FILES make it about 14 seconds slower.

I think my current simple and straightforward implementation
is sufficiently performant up to about 1000 TRUSTED_FILES
but things get noticeably slower if there are thousands
of TRUSTED_FILES which probably won't happen in practice.


[Export of Github issue for rear/rear.]