Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway.
With e.g. new libc or sandbox version (or any number of things...), the syscalls used by file can change which leads to its seccomp filter killing the process. This is an acceptable tradeoff when users are calling file(1), but it makes less sense with trusted input within Portage, especially where it may lead to confusing errors (swallowed within pipes, subshells, etc). Indeed, it might even be the case that file(1) is broken, but the user needs to complete a world upgrade to get a newer file/portage/???, but can't because of various ebuilds (like ones using this eclass) failing. Disable seccomp for these calls to keep working. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <s...@gentoo.org> --- eclass/mono.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/mono.eclass b/eclass/mono.eclass index ddea2d4b9c641..c096acc8c40ee 100644 --- a/eclass/mono.eclass +++ b/eclass/mono.eclass @@ -1,4 +1,4 @@ -# Copyright 1999-2022 Gentoo Authors +# Copyright 1999-2023 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # @ECLASS: mono.eclass @@ -76,7 +76,7 @@ mono_multilib_comply() { then for exe in "${ED}/usr/bin"/* do - if [[ "$(file "${exe}")" == *"shell script text"* ]] + if [[ "$(file -S "${exe}")" == *"shell script text"* ]] then sed -r -i -e ":/lib(/|$): s:/lib(/|$):/$(get_libdir)\1:" \ "${exe}" || die "Sedding some sense into ${exe} failed" -- 2.39.0
