Bug 13768

Summary: base-files do_package fatal error in subprocess
Product: [Build System, Metadata & Runtime] Meta-yocto Reporter: Christopher <jordan.denny5>
Component: meta-yoctoAssignee: Christopher <jordan.denny5>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: Medium+ CC: otavio, poky.bs.watcher, poky.watcher, randy.macleod
Version: 3.4   
Target Milestone: 3.4 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
base-files subprocess error none

Description Christopher 2020-02-02 18:11:21 UTC 
Created attachment 4627 [details]
base-files subprocess error

The recipe for base-files errors in the do_package step due to the subprocess command dying from a received SIGSYS signal. See the attached log for more information. The error was discussed here https://patchwork.openembedded.org/patch/165913/, but the accepted patch did not fix the bug on my system. However the run-time solution given by Richard Purdie solved the issue, by disabling sand-boxing when running the file command.

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index b8585d4253..0c22307c46 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -71,7 +71,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
Comment 1 Randy MacLeod 2020-02-06 15:44:24 UTC 
A proper fix would detect this problem then use a wrapper script but only if seccomp is present.
Comment 2 Christopher 2020-02-16 01:12:30 UTC 
Hey Randy,

So I am not an expert by any means on seccomp, but it seems that detecting that the file program is compiled with this feature is difficult.

I could read the audit log to determine that SIGSYS was indeed produced by an un-allowed system call like seen below

[ 3613.158929] audit: type=1326 audit(1581812421.392:103): auid=1000 uid=1000 gid=1000 ses=2 subj==unconfined pid=6379 comm="file" exe="/usr/bin/file" sig=31 arch=c000003e syscall=39 compat=0 ip=0x7ff59f04a76b code=0x0

Through my research, it seems that I could check /proc/PID/status for the Seccomp flag, but this also doesn't seem viable.

The file command also states for the "-S" option that "On systems where sandboxing is not available, this option has no effect"

It seems like we can safely use this option.
Comment 3 Randy MacLeod 2021-09-23 15:19:28 UTC 
Christopher/Jordan, 
We think this is fixed for most users. What is you host system?
Comment 4 Randy MacLeod 2021-10-14 15:07:33 UTC 
Let us know if there's still a problem.