File's seccomp sandbox does not work under portage's own sandbox. If sys-apps/file was built with USE=seccomp, an invocation from within emerge fails (see bug 728978 as an example). Instead of having to fix all individual packages that call file during build or test, I suggest implementing an ebuild-helper in portage that disables file's seccomp sandbox. Reproducible: Always
Or patch sys-apps/file to disable seccomp when the sandbox variables are present.
Created attachment 645500 [details] bin/ebuild-helpers/file This is a POC created by using bin/ebuild-helpers/bsd/sed as template. Essentially, it adds parameter -S to disable file's sandbox to invocations of file. It was tested by building app-arch/zstd and it lets zstd's test suite pass without error. However, I am not an expert in portage's build environment and didn't do more extensive testing. So, consider this a POC only. Another point one might add, is code to detect whether portages sandbox is enabled and only add -S if it is. A quick search shows that support for libseccomp was added to file sometime in 2017. Therefore, I think that all relevant versions of file support the parameter -S. If this is not the case, the helper shuould also detect whether -S is supported.
(In reply to Sam James (sec padawan) from comment #1) > Or patch sys-apps/file to disable seccomp when the sandbox variables are > present. Or that. I only want my builds and test to succeed. ;-)
> Or patch sys-apps/file to disable seccomp when the sandbox variables are > present. Wouldn't that allow disabling seccomp through potentially steathly set env vars? As-in, even outside of real sandbox. Plus not sure I like the idea of changing applications to suit portage's needs.
Any idea how many ebuilds would actually be affected by this? I'm not sure it makes sense to add a helper to Portage if only a small number of ebuilds are affected.
Inside Portage: > bin/misc-functions.sh: if [[ -z ${soname} && $(file "${D%/}${obj}") == *"SB shared object"* ]]; then > bin/install-qa-check.d/10ignored-flags: f=$(file "${x}") || continue > bin/install-qa-check.d/80multilib-strict: if file "${file}" | grep -Eq "${MULTILIB_STRICT_DENY}" ; then
Are no changes in Portage needed anymore with patch from bug #728978 applied to sys-apps/file?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #7) > Are no changes in Portage needed anymore with patch from bug #728978 applied > to sys-apps/file? Yes, the patch for file seems to be enough. That makes this request obsolete. There is no need to have portage disable the file's sandbox anymore.
