13269 2019-04-08 15:54:32 +0000 Build fails if host 'file' has seccomp enabled 2019-10-19 11:10:11 +0000 1 1 7 Build System, Metadata & Runtime OE-Core oe-core other 0.0.0 x86 Multiple RESOLVED WONTFIX Medium normal 3.1 1 juro.bystricky ross.burton randy.macleod richard.purdie --- New (Never tested) Don't know oldest_to_newest 83482 0 juro.bystricky 2019-04-08 15:54:32 +0000 If the yocto host system has seccomp provisions, any packaging command will fail with the following (example): Command '['file', '-b', '/home/juro/yocto/poky/build-thud/tmp/work/armv5e-poky-linux-gnueabi/file/5.34-r0/package/usr/lib/libmagic.so.1.0.0']' died with <Signals.SIGSYS: 31>.: Traceback (most recent call last): File "/home/juro/yocto/poky/meta/lib/oe/utils.py", line 272, in run ret = self._target(*self._args, **self._kwargs) File "/home/juro/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.7/subprocess.py", line 395, in check_output **kwargs).stdout File "/usr/lib/python3.7/subprocess.py", line 487, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['file', '-b', '/home/juro/yocto/poky/build-thud/tmp/work/armv5e-poky-linux-gnueabi/file/5.34-r0/package/usr/lib/libmagic.so.1.0.0']' died with <Signals.SIGSYS: 31>. ERROR: file-5.34-r0 do_package: Function failed: split_and_strip_files This patch fixes the problem: =================== diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py index efd36b3758..38afeb4244 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", "-bS", path], stderr=subprocess.STDOUT).decode("utf-8") if "ELF" in result: exec_type |= 1 ===================== (see man file "S" option) 83483 1 4464 juro.bystricky 2019-04-08 15:55:13 +0000 Created attachment 4464 patch fixing the reported problem 83485 2 ross.burton 2019-04-08 16:16:07 +0000 Interestingly my build of file-native from master doesn't have a -S option. 83489 3 juro.bystricky 2019-04-08 16:42:05 +0000 On my host: $ file --version file-5.36 magic file from /usr/share/file/magic 83490 4 juro.bystricky 2019-04-08 16:44:10 +0000 (In reply to comment #2) > Interestingly my build of file-native from master doesn't have a -S option. The "file" being used comes from HOSTTOOLS, I am not sure why we don't use our file-native. 84619 5 ross.burton 2019-08-08 15:19:30 +0000 What host distro was this? I'm guessing Clear Linux. Can you still replicate this? There's presumably some conflict between seccomp and pseudo. I wonder if it's possible to disable seccomp in file without passing an option so we don't need to detect if seccomp is enabled before every invocation of file. 84620 6 ross.burton 2019-08-08 15:20:04 +0000 Current thinking is "can we just mandate that seccomp isn't enabled"? 84621 7 juro.bystricky 2019-08-08 15:27:54 +0000 (In reply to comment #6) > Current thinking is "can we just mandate that seccomp isn't enabled"? The latest "file" allows the switch -S without seccomp being available. (Up until then -S was treated as an error in that case). But it will take some time for this to percolate to all distros. So the patch I posted will not work with the old "file" package. 84622 8 ross.burton 2019-08-08 15:30:58 +0000 Yes, I saw that. It landed in file five days ago and we still support Centos 7 which is based on Fedora 19, so I don't expect to be able to assume 'file -S' works for a good few years yet. 84710 9 ross.burton 2019-08-19 11:36:25 +0000 Interestingly LWN has an article about how Debian tried enabling seccomp for file, and had to turn it off because they use fakeroot (thus, LD_PRELOAD) during package building too: https://lwn.net/SubscriberLink/796108/95ab278a062b5838/ 84729 10 randy.macleod 2019-08-22 14:58:23 +0000 We expect that seccomp for file does now work in general and any distro trying to do so will eventually revet that feature. 84735 11 randy.macleod 2019-08-22 16:28:36 +0000 Correction: seccomp for 'file' does *not* work in general 85372 12 ross.burton 2019-10-17 15:10:39 +0000 Clear agree that seccomp is stupid and are reverting this. 85398 13 ross.burton 2019-10-19 11:10:11 +0000 GNU file and seccomp and LD_PRELOAD (thus, pseudo) just don't get on. As per comment #9 this isn't specific to us, Debian has come to the same conclusion. Clear was the only distribution that enabled seccomp in file and as of this commit it doesn't do that any more: https://github.com/clearlinux-pkgs/file/commit/74624ebb5d803a9ce7cd8c956830983f54451d41 Closing as WONTFIX. I guess an alternative would be to remove file-native from ASSUME_PROVIDED on these platforms and ensure that file-native is marked as a dependency where it is used, but I don't know if this would actually be possible. 4464 2019-04-08 15:55:13 +0000 2019-04-08 15:55:13 +0000 patch fixing the reported problem package.py.patch text/plain 524 juro.bystricky ZGlmZiAtLWdpdCBhL21ldGEvbGliL29lL3BhY2thZ2UucHkgYi9tZXRhL2xpYi9vZS9wYWNrYWdl LnB5CmluZGV4IGVmZDM2YjM3NTguLjM4YWZlYjQyNDQgMTAwNjQ0Ci0tLSBhL21ldGEvbGliL29l L3BhY2thZ2UucHkKKysrIGIvbWV0YS9saWIvb2UvcGFja2FnZS5weQpAQCAtNjcsNyArNjcsNyBA QCBkZWYgaXNfa2VybmVsX21vZHVsZV9zaWduZWQocGF0aCk6CiAjIDE2IC0ga2VybmVsIG1vZHVs ZQogZGVmIGlzX2VsZihwYXRoKToKICAgICBleGVjX3R5cGUgPSAwCi0gICAgcmVzdWx0ID0gc3Vi cHJvY2Vzcy5jaGVja19vdXRwdXQoWyJmaWxlIiwgIi1iIiwgcGF0aF0sIHN0ZGVycj1zdWJwcm9j ZXNzLlNURE9VVCkuZGVjb2RlKCJ1dGYtOCIpCisgICAgcmVzdWx0ID0gc3VicHJvY2Vzcy5jaGVj a19vdXRwdXQoWyJmaWxlIiwgIi1iUyIsIHBhdGhdLCBzdGRlcnI9c3VicHJvY2Vzcy5TVERPVVQp LmRlY29kZSgidXRmLTgiKQogCiAgICAgaWYgIkVMRiIgaW4gcmVzdWx0OgogICAgICAgICBleGVj X3R5cGUgfD0gMQo=