Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#56289 - [systemd, libseccomp] statx syscall is blocked in containers

Attached to Project: Arch Linux
Opened by Antonio Rojas (arojas) - Friday, 10 November 2017, 10:24 GMT
Last edited by Christian Hesse (eworm) - Wednesday, 10 January 2018, 20:48 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Please backport https://github.com/systemd/systemd/commit/8e6a7a8b2be409d356bcaface00f6d44390c07ff to our systemd package so that statx syscalls work in containers, which is needed to build Qt 5.10
This task depends upon

Closed by  Christian Hesse (eworm)
Wednesday, 10 January 2018, 20:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  libseccomp 2.3.2-2 in [testing]
Comment by Antonio Rojas (arojas) - Friday, 10 November 2017, 23:03 GMT
235.38-2 fixes the issue on my laptop. However it doesn't on my desktop: even though 'systemd-analyze syscall-filter' shows statx is whitelisted, it is still being blocked in containers for some reason. Hopefully it will work on soyuz
Comment by Antonio Rojas (arojas) - Sunday, 12 November 2017, 09:33 GMT
As I feared, it doesn't work on soyuz. systemd is still blocking statx on containers in some machines for some reason. The only difference I can think of is that my laptop's filesystem is ext4, and my desktop's (and soyuz's) is btrfs.
Comment by Christian Hesse (eworm) - Sunday, 12 November 2017, 21:11 GMT
But soyuz has mounted tmpfs on /var/lib/archbuild.
Comment by Antonio Rojas (arojas) - Monday, 13 November 2017, 11:22 GMT
Did a fresh install on an ext4 partition on my desktop machine: still doesn't work. I have no clue what's going on here. Enabling systemd debug log doesn't give any relevant info.
Comment by Antonio Rojas (arojas) - Monday, 13 November 2017, 11:34 GMT
OK, found it - it's libseccomp. Seems I had a patched version on my laptop with statx support and had forgotten about it. Looks like syscalls not known to libseccomp are automatically blocked by systemd.
So either statx support needs to be added in libseccomp (which is not even merged upstream yet - https://github.com/seccomp/libseccomp/pull/100) or this needs to be somehow worked around in systemd. What a major fuckup.
Comment by Christian Hesse (eworm) - Monday, 13 November 2017, 11:43 GMT
I think the proper way is to patch libseccomp... Anybody should raise the priority for the libseccomp statx pull request. :-p
Comment by loqs (loqs) - Monday, 13 November 2017, 17:42 GMT
statx was introduced in linux 4.11 so would that be an issue for qt 5.10 under linux-lts until it is rebased to 4.14?
Comment by Antonio Rojas (arojas) - Tuesday, 14 November 2017, 11:03 GMT
@loqs yes. The feature is enabled depending on the linux-api-headers version available at build time, which is independent of the kernel version itself.
Comment by Antonio Rojas (arojas) - Wednesday, 10 January 2018, 18:09 GMT
The libseccomp part of the fix has finally been merged https://github.com/seccomp/libseccomp/commit/4793ea990ea80ee26ed63e2a20723fdb417abf5b
Can we get this in our package? Currently I have to patch out statx from Qt.

Loading...