Package: libseccomp2
Version: 2.3.1-2.1
Followup-For: Bug #895417
Hello,
I wholeheartedly concur with Simon: as of libseccomp 2.3.1 (and 2.3.2), trying
to run Qt5 applications with seccomp-based syscall filtering (e.g. in a
systemd-nspawn container) results in exit code 134 along with the following
error message:
This application failed to start because it could not find or load the Qt
platform plugin "xcb"
in "".
Reinstalling the application may fix this problem.
Aborted
This remains a very obscure message; it gets more interesting after:
export QT_DEBUG_PLUGINS=1
which allows us to get a more detailed output, including messages such as:
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so: Cannot allocate
memory
An strace-based investigation quickly reveals the actual issue: statx()
syscalls get denied with EPERM; the Qt library, not expecting such a result
from statx() ends up calling mmap() with a zero length, resulting in EINVAL and
in the previous error messages:
openat(AT_FDCWD,
"/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so",
O_RDONLY|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, 0x7ffe42110950)
= -1 EPERM (Operation not permitted)
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, 0x7ffe42110a50)
= -1 EPERM (Operation not permitted)
mmap(NULL, 0, PROT_READ, MAP_SHARED, 3, 0) = -1 EINVAL (Invalid argument)
Without seccomp filtering, the normal behaviour results in:
openat(AT_FDCWD,
"/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so",
O_RDONLY|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
{stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=10520,
...}) = 0
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
{stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=10520,
...}) = 0
mmap(NULL, 10520, PROT_READ, MAP_SHARED, 3, 0) = 0x7fb9a53d7000
After some extra investigations, it becomes clear that both the kernel and
systemd-nspawn know about the statx() syscall. Specifically, systemd-nspawn
already whitelists the statx() syscall as part of its "@file-system" syscall
group. However, libseccomp < 2.3.3 knows nothing about "statx" and ends up
denying it.
I have manually compiled libseccomp 2.3.3 and confirm that it solves the issue
above (probably among others).
Long story short: it would indeed be really helpful to package the new upstream
version 2.3.3.
Cheers,
Xavier
