[OE-core] [PATCH] file: explicitly disable seccomp

Khem Raj raj.khem at gmail.com
Mon Jan 20 15:45:39 UTC 2020


On Mon, Jan 20, 2020 at 4:53 AM Martin Hundebøll <martin at geanix.com> wrote:
>
> On 18/10/2019 23.28, Richard Purdie wrote:
> > On Fri, 2019-10-18 at 18:03 +0530, Khem Raj wrote:
> >>
> >>
> >> On Fri, Oct 18, 2019 at 4:58 PM Ross Burton <ross.burton at intel.com>
> >> wrote:
> >>> file will automatically enable seccomp if the seccomp headers are
> >>> available, but
> >>> the build will fail on Opensuse Tumbleweed because the include
> >>> paths are wrong.
> >>>
> >>> Enabling seccomp is a bad idea because it interacts badly with
> >>> pseudo (causing
> >>> build failures), so explicitly and globally disable seccomp.
> >>>
> >>> Signed-off-by: Ross Burton <ross.burton at intel.com>
> >>> ---
> >>>   meta/recipes-devtools/file/file_5.37.bb | 2 ++
> >>>   1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/meta/recipes-devtools/file/file_5.37.bb
> >>> b/meta/recipes-devtools/file/file_5.37.bb
> >>> index a840dbc012b..c53a120b840 100644
> >>> --- a/meta/recipes-devtools/file/file_5.37.bb
> >>> +++ b/meta/recipes-devtools/file/file_5.37.bb
> >>> @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
> >>>
> >>>   inherit autotools update-alternatives
> >>>
> >>> +EXTRA_OECONF += "--disable-libseccomp"
> >>> +
> >>
> >> On host it makes sense but how about for target recipe ? We do have
> >> libseccomp support
> >> Perhaps it’s best to disable it for native and native sdk alone ?
> >
> > Given the problem reports in the media and the decisions made by most
> > other distros I think disabling this is probably safest until its been
> > make more usable (no other distro is shipping this enabled now).
>
> Arch Linux enabled libseccomp as of today:
>
> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/file&id=a52fa0a37bad1f4ab67a934a4e0025e70aa1fd0e
>
> This breaks the use of `file` in do_package():
>
> ERROR: base-files-3.0.14-r89 do_package: Fatal errors occurred in
> subprocesses:
>
> Command '['file', '-b',
> '/home/martin/clients/connectedcars/yocto/build/tmp-glibc/work/iwg26-oe-linux-gnueabi/base-files/3.0.14-r89/package/etc/skel/.profile']'
> died with <Signals.SIGSYS: 31>.: Traceback (most recent call last):
>
>    File
> "/home/martin/clients/connectedcars/yocto/poky/meta/lib/oe/utils.py",
> line 272, in run
>
>      ret = self._target(*self._args, **self._kwargs)
>
>    File
> "/home/martin/clients/connectedcars/yocto/poky/meta/lib/oe/package.py",
> line 70, in is_elf
>
>      result = subprocess.check_output(["file", "-b", path],
> stderr=subprocess.STDOUT).decode("utf-8")
>
>    File "/usr/lib/python3.8/subprocess.py", line 411, in check_output
>
>      return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
>
>    File "/usr/lib/python3.8/subprocess.py", line 512, in run
>
>
>      raise CalledProcessError(retcode, process.args,
>
> subprocess.CalledProcessError: Command '['file', '-b',
> '/home/martin/clients/connectedcars/yocto/build/tmp-glibc/work/iwg26-oe-linux-gnueabi/base-files/3.0.14-r89/package/etc/skel/.profile']'
> died with <Signals.SIGSYS: 31>.
>
> Disabling libseccomp sandboxing at runtime fixes it for me:
>
> diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
>
> index efd36b3758..bc46d7c27c 100644
>
> --- a/meta/lib/oe/package.py
>
> +++ b/meta/lib/oe/package.py
>
> @@ -67,7 +67,7 @@ def is_kernel_module_signed(path):
>
>   # 16 - kernel module
>
>   def is_elf(path):
>
>       exec_type = 0
>
> -    result = subprocess.check_output(["file", "-b", path],
> stderr=subprocess.STDOUT).decode("utf-8")
>
> +    result = subprocess.check_output(["file", "-S", "-b", path],
> stderr=subprocess.STDOUT).decode("utf-8")
>

pseudo needs some love since it alters syscalls which go out of bounds
what is allowed by libseccomp until then pin your file version to 5.37
in arch till a supported distro is affected by same problem. It wont
be long better option is to fix pseudo

>
>
>       if "ELF" in result:
>
>           exec_type |= 1
>
>


More information about the Openembedded-core mailing list