summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSam James <sam@gentoo.org>2023-01-03 04:02:24 +0000
committerSam James <sam@gentoo.org>2023-01-05 00:33:06 +0000
commitc5d40af3c56436cdbf774707cb36a8cdc832b3dd (patch)
tree2760674023524783e878c3489e6aea2c6e951cd8 /sys-devel/mold
parentmono.eclass: pass -S to file to disable seccomp (diff)
downloadgentoo-c5d40af3c56436cdbf774707cb36a8cdc832b3dd.tar.gz
gentoo-c5d40af3c56436cdbf774707cb36a8cdc832b3dd.tar.bz2
gentoo-c5d40af3c56436cdbf774707cb36a8cdc832b3dd.zip
unpacker.eclass: pass -S to file to disable seccomp
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 <sam@gentoo.org>
Diffstat (limited to 'sys-devel/mold')
0 files changed, 0 insertions, 0 deletions