#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.]