Summary: | sys-apps/file-5.40-r1[seccomp] with FEATURES="sandbox" - SIGSYS on fstatat64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christian Bricart <christian> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alex, christian, sam, sandbox |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
strace'ed build log from ~arm
strace'ed build.log from ~x86 successful strace'ed build.log from x86 successful strace'ed build.log from x86 emerge --info file-5.40-r1 build.log |
Description
Christian Bricart
2021-04-21 20:20:06 UTC
*** Bug 784860 has been marked as a duplicate of this bug. *** 1) if you can, please strace the failing file invocation during build 2) please post emerge —-info from failing and successful builds (make clear which) 3) post build.logs too 4) please try this patch which I’ve been meaning to file a bug to include: https://github.com/file/file/commit/abcd583135bb0762e6bfd0f2e06c50bea1fb3cd0 (put it in /etc/portage/patches/sys-apps/file) (I’m on mobile so can’t check easily but that dmesg snippet may be enough. Please tell us which arch it is from though because syscall numbers vary. So, to reiterate, please make clear which output is from which system.) first is from ~arm - second from ~x86 (also identifiable from the exe=/var/tmp/portage/..) (In reply to Christian Bricart from comment #4) > first is from ~arm - second from ~x86 (also identifiable from the > exe=/var/tmp/portage/..) I did mention I’m on mobile :) Anyway, the information is still needed to figure out which syscall table to check (kernel version) no hurry on mobile :) ~x86 is:1 > Linux version 5.11.15-gentoo-eeebox-4 (root@eeebox) (i686-pc-linux-gnu-gcc-10.3.0 (Gentoo 10.3.0 p1) 10.3.0, GNU ld (Gentoo 2.35.2 p1) 2.35.2) #1 SMP Mon Apr 19 11:22:16 CEST 2021 ~arm uses upstream git checkout from github.com/raspberrypi/linux - rpi-5.10.y branch: > Linux version 5.10.25-v7+ (root@pi) (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 10.2.0-r5 p6) 10.2.0, GNU ld (Gentoo 2.35.2 p1) 2.35.2) #7 SMP Thu Apr 1 03:25:52 CEST 2021 meanwhile, I've tried your patch from 4) - no change, still does not merge on both arches. actually, the patch mentiones "ARM64" - though, these failing arches are "armv7l" and "x86". sorry- I do not have an arm64 on hand. manged to patch strace into the failing invocation. uploading both failing build.log Created attachment 701556 [details]
strace'ed build log from ~arm
Created attachment 701559 [details]
strace'ed build.log from ~x86
Created attachment 701565 [details]
successful strace'ed build.log from x86
tried re-merging (with strace) on a stable x86 host -> success
Created attachment 701568 [details]
successful strace'ed build.log from x86
re-merged with LC_ALL=C ..
I would like to confirm this exact same bug on my x86 gentoo system USE="-seccomp" emerge sys-apps/file indeed compiles fine It would be really helpful to have emerge --info from a failing system. I am especially interested in the glibc version. Created attachment 702021 [details]
emerge --info
Created attachment 702024 [details]
file-5.40-r1 build.log
build.log
It looks like the fstatat64 syscall is coming from sys-apps/sandbox. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0813d843cb2a43c748fdf6c9d5ac6dc882104dcf commit 0813d843cb2a43c748fdf6c9d5ac6dc882104dcf Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-04-23 19:10:09 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-04-23 19:10:09 +0000 sys-apps/file: allow faccessat and fstatat64 syscalls Closes: https://bugs.gentoo.org/784857 Signed-off-by: Mike Gilbert <floppym@gentoo.org> .../{file-5.40-r1.ebuild => file-5.40-r2.ebuild} | 2 ++ .../file/files/file-5.40-seccomp-faccessat.patch | 34 ++++++++++++++++++++++ .../file/files/file-5.40-seccomp-fstatat64.patch | 29 ++++++++++++++++++ 3 files changed, 65 insertions(+) thank you Mike, the patches indeed fixed emerging with =sys-apps/file-5.40-r2 both on ~arm and ~x86 However, you will also have to backport this to (stable) =sys-apps/file-5.39-r4 which still fails to merge. thank you (In reply to Christian Bricart from comment #19) I was unable to reproduce the issue on a stale x86 system. I suspect it only happens when sys-apps/sandbox has been compiled against glibc-2.33. you are correct for a fully stable system. Though I've just also tried to explicitly emerge =sys-apps/file-5.39-r4 on a otherwise fully ~arm and also otherwise fully ~x86 system. And that obviously fails too. So I've thought it should be functional in any combination one may think of it should not require a revbump for the stable package though We do not require that stable packages function correctly with unstable dependencies. Regardless, I opened bug 785292 to stabilize the new version of sys-apps/file. |