Bug 728992 – sys-apps/portage: Add ebuild-helper to disable file's seccomp sandbox

• Product: Portage Development
• Status: RESOLVED OBSOLETE

[Description tka 2020-06-21 11:25:54 UTC]

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

[Comment 1 Sam James 2020-06-21 11:32:21 UTC]

Or patch sys-apps/file to disable seccomp when the sandbox variables are present.

[Comment 2 tka 2020-06-21 11:42:31 UTC]

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.

[Comment 3 tka 2020-06-21 11:44:22 UTC]

(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. ;-)

[Comment 4 Ionen Wolkens 2020-06-21 14:32:31 UTC]

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

[Comment 5 Mike Gilbert 2020-06-21 14:53:04 UTC]

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.

[Comment 6 Arfrever Frehtes Taifersar Arahesis 2020-06-23 08:41:22 UTC]

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

[Comment 7 Arfrever Frehtes Taifersar Arahesis 2020-06-23 21:01:52 UTC]

Are no changes in Portage needed anymore with patch from bug #728978 applied to sys-apps/file?

[Comment 8 tka 2020-06-24 22:42:42 UTC]

(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.