Since around 5.38 [0], support has improved quite a bit [1]. Can we at least expose the USE flag in non-live ebuilds? (although ideally default eventually). [0] https://mailman.astron.com/pipermail/file/2019-July/000175.html [1] https://mailman.astron.com/pipermail/file/2019-July/000175.html
seccomp is particularly apt here given file is often used on untrusted file. IIRC OpenBSD implemented a sandboxed/privseped file, that may be worth an investigation too.
Have you even tried the live ebuild with USE="seccomp"? If yes you'd have noticed that compilation fails: make[2]: Entering directory '/var/tmp/portage/sys-apps/file-9999/work/file-9999-abi_x86_64.amd64/magic' ../src/file -C -m magic make[2]: *** [Makefile:828: magic.mgc] Bad system call make[2]: Leaving directory '/var/tmp/portage/sys-apps/file-9999/work/file-9999-abi_x86_64.amd64/magic' make[1]: *** [Makefile:458: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-apps/file-9999/work/file-9999-abi_x86_64.amd64' make: *** [Makefile:367: all] Error 2 So unless we get this issue fixed, non-live ebuild will only get the USE flag if being p.use.mask-ed.
(In reply to Lars Wendler (Polynomial-C) from comment #2) > Have you even tried the live ebuild with USE="seccomp"? If yes you'd have > noticed that compilation fails: > Sure, that's the aim here - figure out what the blockers are, and work through them. If it all worked, there'd be no fun. My build of file-5.38 dies in the same place: >Making all in magic >make[2]: Entering directory '/var/tmp/portage/sys-apps/file-5.38/work/file-5.38-abi_x86_64.amd64/magic' >../src/file -C -m magic >make[2]: *** [Makefile:828: magic.mgc] Bad system call >make[2]: Leaving directory '/var/tmp/portage/sys-apps/file-5.38/work/file-5.38-abi_x86_64.amd64/magic' >make[1]: *** [Makefile:400: all-recursive] Error 1 >make[1]: Leaving directory '/var/tmp/portage/sys-apps/file-5.38/work/file-5.38-abi_x86_64.amd64' >make: *** [Makefile:332: all] Error 2 Works fine w/o sandbox: >$ ../src/file -C -m magic [runs fine] and >$ sandbox ../src/file -C -m magic >Sandboxed process killed by signal: Bad system call >Bad system call (core dumped)
From my investigation so far, it seems this is the situation: * sandbox needs more permissions than file (as you'd expect) * file requests these * sandbox uses something extra in its duties, gets killed. The binary produced works fine to create the magic file outside of the sandbox or with the sandbox on and seccomp disabled with the -S flag. Rather than patch seccomp.c to include the (likely far excessive) powers sandbox needs, one fix is to just patch the Makefile to call file with -S during the compile process. I'll do more research and see if I run into any issues.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6da8c8078434cfa0e3ec7334de28b27467a0a0b5 commit 6da8c8078434cfa0e3ec7334de28b27467a0a0b5 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2020-06-15 08:02:37 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2020-06-15 08:09:14 +0000 sys-apps/file: Bump to version 5.39 Closes: https://bugs.gentoo.org/713710 Package-Manager: Portage-2.3.101, Repoman-2.3.22 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-apps/file/Manifest | 1 + sys-apps/file/file-5.39.ebuild | 140 +++++++++++++++++++++ .../file/files/file-5.39-seccomp_sandbox.patch | 13 ++ 3 files changed, 154 insertions(+)
Bug seems to have resurfaced, in file-5.40-r1.
