[PATCH] file: explicitly disable seccomp

[PATCH] file: explicitly disable seccomp

[Ross Burton]

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@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"
+
 ALTERNATIVE_${PN} = "file"
 ALTERNATIVE_LINK_NAME[file] = "${bindir}/file"
 
-- 
2.20.1

Re: [PATCH] file: explicitly disable seccomp

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

On Fri, Oct 18, 2019 at 4:58 PM Ross Burton <ross.burton@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@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 ?

>
>  ALTERNATIVE_${PN} = "file"
>  ALTERNATIVE_LINK_NAME[file] = "${bindir}/file"
>
> --
> 2.20.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2545 bytes --]

Re: [PATCH] file: explicitly disable seccomp

[Richard Purdie]

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

Cheers,

Richard

Re: [PATCH] file: explicitly disable seccomp

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

On Sat, Oct 19, 2019 at 2:58 AM Richard Purdie <
richard.purdie@linuxfoundation.org> 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@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@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).
>

Ok makes sense


> Cheers,
>
> Richard
>
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2894 bytes --]

Re: [PATCH] file: explicitly disable seccomp

[Martin Hundebøll]

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@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@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")



      if "ELF" in result:

          exec_type |= 1

Re: [PATCH] file: explicitly disable seccomp

[Khem Raj]

On Mon, Jan 20, 2020 at 4:53 AM Martin Hundebøll <martin@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@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@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
>
>

Re: [PATCH] file: explicitly disable seccomp

[Ross Burton]

On 20/01/2020 15:45, Khem Raj wrote:
> 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

That's not quite right.  pseudo LD_PRELOADs itself into file, and makes 
syscalls which are not whitelisted in file's seccomp configuration.

There's nothing pseudo can do to solve this.

Ross

Re: [PATCH] file: explicitly disable seccomp

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

On Mon, Jan 20, 2020 at 9:10 AM Ross Burton <ross.burton@intel.com> wrote:

> On 20/01/2020 15:45, Khem Raj wrote:
> > 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
>
> That's not quite right.  pseudo LD_PRELOADs itself into file, and makes
> syscalls which are not whitelisted in file's seccomp configuration.
>

It’s is not different than what I was saying how it inserts itself into
process is a detail which is hidden from operating system

However I think file is only one case when used along with libseccomp there
could be more use cases if other host tools we use start using it

So I wonder If we should start building own native versions of tools or
make it part of build tools tarball
Or perhaps just publish a self built container and not worry about what
distros are doing underneath

>
> There's nothing pseudo can do to solve this.
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 1685 bytes --]

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

[Jan Luebbe]

Hi,

On Mon, 2020-01-20 at 17:10 +0000, Ross Burton wrote:
> On 20/01/2020 15:45, Khem Raj wrote:
> > 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
> 
> That's not quite right.  pseudo LD_PRELOADs itself into file, and makes 
> syscalls which are not whitelisted in file's seccomp configuration.
> 
> There's nothing pseudo can do to solve this.

I stumbled across this thread when checking why libseccomp is not in
oe-core or meta-oe. It seems to me that pseudo could intercept the
seccomp(2) or libseccomps seccomp_* function calls and report them as
unsupported to simulate running on a kernel without seccomp support.

What am I missing? :)

Regards,
Jan

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

[Richard Purdie]

On Tue, 2020-03-31 at 12:57 +0200, Jan Luebbe wrote:
> Hi,
> 
> On Mon, 2020-01-20 at 17:10 +0000, Ross Burton wrote:
> > On 20/01/2020 15:45, Khem Raj wrote:
> > > 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
> > 
> > That's not quite right.  pseudo LD_PRELOADs itself into file, and
> > makes 
> > syscalls which are not whitelisted in file's seccomp configuration.
> > 
> > There's nothing pseudo can do to solve this.
> 
> I stumbled across this thread when checking why libseccomp is not in
> oe-core or meta-oe. It seems to me that pseudo could intercept the
> seccomp(2) or libseccomps seccomp_* function calls and report them as
> unsupported to simulate running on a kernel without seccomp support.
> 
> What am I missing? :)

I don't think we'd thought of that, I like the idea in principle...

Cheers,

Richard

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

[Richard Purdie]

On Tue, 2020-03-31 at 12:57 +0200, Jan Luebbe wrote:
> Hi,
> 
> On Mon, 2020-01-20 at 17:10 +0000, Ross Burton wrote:
> > On 20/01/2020 15:45, Khem Raj wrote:
> > > 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
> > 
> > That's not quite right.  pseudo LD_PRELOADs itself into file, and
> > makes 
> > syscalls which are not whitelisted in file's seccomp configuration.
> > 
> > There's nothing pseudo can do to solve this.
> 
> I stumbled across this thread when checking why libseccomp is not in
> oe-core or meta-oe. It seems to me that pseudo could intercept the
> seccomp(2) or libseccomps seccomp_* function calls and report them as
> unsupported to simulate running on a kernel without seccomp support.
> 
> What am I missing? :)

I made a guess at a patch:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=d675ff53d3ccbc6bd7db5f067d331bf3f94de5cd

Just need someone with a system that can test it now!

Cheers,

Richard

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

[Khem Raj]

On Fri, Apr 3, 2020 at 6:36 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2020-03-31 at 12:57 +0200, Jan Luebbe wrote:
> > Hi,
> >
> > On Mon, 2020-01-20 at 17:10 +0000, Ross Burton wrote:
> > > On 20/01/2020 15:45, Khem Raj wrote:
> > > > 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
> > >
> > > That's not quite right.  pseudo LD_PRELOADs itself into file, and
> > > makes
> > > syscalls which are not whitelisted in file's seccomp configuration.
> > >
> > > There's nothing pseudo can do to solve this.
> >
> > I stumbled across this thread when checking why libseccomp is not in
> > oe-core or meta-oe. It seems to me that pseudo could intercept the
> > seccomp(2) or libseccomps seccomp_* function calls and report them as
> > unsupported to simulate running on a kernel without seccomp support.
> >
> > What am I missing? :)
>
> I made a guess at a patch:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=d675ff53d3ccbc6bd7db5f067d331bf3f94de5cd
>
> Just need someone with a system that can test it now!
>

seems pseudo still has same issue with archlinux latest file
(file-5.38-3) utility

Command '['file', '-b',
'/mnt/b/yoe/build/tmp/work/aarch64-yoe-linux/glibc/2.31+gitAUTOINC+71f2b249a2-r0/package/lib/libnss_db-2.31.so']'
died with <Signals.SIGSYS: 31>.: Traceback (most recent call last):
  File "/mnt/b/yoe/sources/openembedded-core/meta/lib/oe/utils.py",
line 280, in run
    ret = self._target(*self._args, **self._kwargs)
  File "/mnt/b/yoe/sources/openembedded-core/meta/lib/oe/package.py",
line 74, 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,

> Cheers,
>
> Richard
>

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

[Richard Purdie]

On Fri, 2020-04-03 at 07:23 -0700, Khem Raj wrote:
> On Fri, Apr 3, 2020 at 6:36 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Tue, 2020-03-31 at 12:57 +0200, Jan Luebbe wrote:
> > > Hi,
> > > 
> > > On Mon, 2020-01-20 at 17:10 +0000, Ross Burton wrote:
> > > > On 20/01/2020 15:45, Khem Raj wrote:
> > > > > 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
> > > > 
> > > > That's not quite right.  pseudo LD_PRELOADs itself into file, and
> > > > makes
> > > > syscalls which are not whitelisted in file's seccomp configuration.
> > > > 
> > > > There's nothing pseudo can do to solve this.
> > > 
> > > I stumbled across this thread when checking why libseccomp is not in
> > > oe-core or meta-oe. It seems to me that pseudo could intercept the
> > > seccomp(2) or libseccomps seccomp_* function calls and report them as
> > > unsupported to simulate running on a kernel without seccomp support.
> > > 
> > > What am I missing? :)
> > 
> > I made a guess at a patch:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=d675ff53d3ccbc6bd7db5f067d331bf3f94de5cd
> > 
> > Just need someone with a system that can test it now!
> > 
> 
> seems pseudo still has same issue with archlinux latest file
> (file-5.38-3) utility
> 
> Command '['file', '-b',
> '/mnt/b/yoe/build/tmp/work/aarch64-yoe-linux/glibc/2.31+gitAUTOINC+71f2b249a2-r0/package/lib/libnss_db-2.31.so']'
> died with <Signals.SIGSYS: 31>.: Traceback (most recent call last):
>   File "/mnt/b/yoe/sources/openembedded-core/meta/lib/oe/utils.py",
> line 280, in run
>     ret = self._target(*self._args, **self._kwargs)
>   File "/mnt/b/yoe/sources/openembedded-core/meta/lib/oe/package.py",
> line 74, 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,

There is a pretty horrendous hack in master-next which avoids this (I
think). I went through the following:

a) Disabling seccomp syscall. It falls back to prctl().

b) Disabling prctl() (which is variadac) means file exits with an
error, seccomp must be enabled.

c) Return success but do nothing (don't load the seccomp program)

It appears that returning success works.

Not convinced we want to do that mind...

Cheers,

Richard