Qt doesn't work in my ArchLinux docker
-
Have you had success using the seccomp file or updating to 18.06?
@emberflare At first I succeeded with 18.03 and the downloaded seccomp profile file. Afterwards I made an upgrade to 18.06 and did not need the seccomp profile file anymore.
I gave an example calibre Dockerfile in the bugreport that I used for test runs. Can you check whether that one succeeds on your system?
Another possible check: run with
--cap-add=ALL.Next check: Add to your seccomp profile whitelist syscalls not covered by
--cap-add=ALL:"add_key","get_kernel_syms","keyctl","move_pages","nfsservctl","perf_event_open","personality","query_module","request_key","sysfs","_sysctl","uselib","userfaultfd","ustat",Here's my minimal Dockerfile for reproducing the error.
It succeeds here with
Docker version 18.06.1-ce, build e68fc7aand outputQStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'.wrote on 10 Sept 2018, 10:47 last edited by emberflare 9 Oct 2018, 10:51@mviereck said in Qt doesn't work in my ArchLinux docker:
I gave an example calibre Dockerfile in the bugreport that I used for test runs. Can you check whether that one succeeds on your system?
Running that image fails for me with the usual error:
Could not find the Qt platform plugin "xcb" in "".Another possible check: run with
--cap-add=ALL.This fails with my minimal Dockerfile, and with your calibre Dockerfile.
Next check: Add to your seccomp profile whitelist syscalls not covered by
--cap-add=ALL:This fails with my minimal Dockerfile, and with your calibre Dockerfile.
Here's my minimal Dockerfile for reproducing the error.
It succeeds here with
Docker version 18.06.1-ce, build e68fc7aand outputQStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'.That is very strange. Perhaps my Docker installation is corrupted or my host is somehow incapable of applying seccomp configurations. In one of the PRs linked to this problem, somebody mentions a host dependency for seccomps, but it seems unlikely that they are missing on ubuntu 18.04.
I'll reinstall Docker and report back with the results.
EDIT: Same results with reinstalled docker. I'm looking into seccomp dependencies now.
-
wrote on 10 Sept 2018, 12:19 last edited by
@emberflare Maybe different kernel versions make a difference. Here:
$ uname -a Linux buster 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 GNU/LinuxI'll reinstall Docker and report back with the results.
Make sure you don't have package
docker.ioinstalled. It interferes withdocker-ce. Also there may be an old docker config file somewhere around that messes up your setup. Maybe purge-deinstalldocker-ce, than installdocker.io, purge it, too, than installdocker-ceagain. That hopefully removes all config files.somebody mentions a host dependency for seccomps
Afaik the kernel can be compiled to support seccomp or not. If it does not support it, there should be no restriction.
-
@emberflare Maybe different kernel versions make a difference. Here:
$ uname -a Linux buster 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 GNU/LinuxI'll reinstall Docker and report back with the results.
Make sure you don't have package
docker.ioinstalled. It interferes withdocker-ce. Also there may be an old docker config file somewhere around that messes up your setup. Maybe purge-deinstalldocker-ce, than installdocker.io, purge it, too, than installdocker-ceagain. That hopefully removes all config files.somebody mentions a host dependency for seccomps
Afaik the kernel can be compiled to support seccomp or not. If it does not support it, there should be no restriction.
wrote on 12 Sept 2018, 07:48 last edited by@emberflare Maybe different kernel versions make a difference. Here:
$ uname -a Linux buster 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 GNU/LinuxMy host is a Google Cloud instance, with a seemingly custom compiled kernel (
gcpsuffix):$ uname -a Linux gpu-instance-1 4.15.0-1018-gcp #19~16.04.2-Ubuntu SMP Mon Aug 20 13:39:28 UTC 2018 x86_64 x86_64 x86_64 GNU/LinuxPerhaps the problem lies in that kernel, but as you mentioned, it should either be compiled to support seccomp or not, and theoretically work in both cases. Could a kernel update help?
I'll reinstall Docker and report back with the results.
purge-deinstall
docker-ce, than installdocker.io, purge it, too, than installdocker-ceagainGood idea, I tried this, but still the same error.
-
wrote on 12 Sept 2018, 08:56 last edited by
I found an interesting documentation about seccomp and docker: https://github.com/docker/labs/tree/master/security/seccomp
It may be worth a try to check which syscalls your qt app is using and whether one is missing in the seccomp whitelist.
Installstracein image, run it interactive-itwith bash and try:strace -c -f -S name /opt/qt511/bin/qmlplugindump 2>&1 1>/dev/null | tail -n +3 | head -n -2 | awk '{print $(NF)}'strace probably needs
--cap-add SYS_PTRACE. If in doubt, try--cap-add=ALL.This blog post may help, too: https://blog.jessfraz.com/post/how-to-use-new-docker-seccomp-profiles/
I did not check all that above yet, I will look closer at this later.
-
I found an interesting documentation about seccomp and docker: https://github.com/docker/labs/tree/master/security/seccomp
It may be worth a try to check which syscalls your qt app is using and whether one is missing in the seccomp whitelist.
Installstracein image, run it interactive-itwith bash and try:strace -c -f -S name /opt/qt511/bin/qmlplugindump 2>&1 1>/dev/null | tail -n +3 | head -n -2 | awk '{print $(NF)}'strace probably needs
--cap-add SYS_PTRACE. If in doubt, try--cap-add=ALL.This blog post may help, too: https://blog.jessfraz.com/post/how-to-use-new-docker-seccomp-profiles/
I did not check all that above yet, I will look closer at this later.
wrote on 12 Sept 2018, 12:15 last edited by@mviereck Thanks for the command! The syscalls used by my application are the following:
access, arch_prctl, brk, close, connect, execve, fstat, futex, getcwd, getdents, geteuid, getpid, getrandom, getuid, lseek, lstat, mmap, mprotect, munmap, openat, prlimit64, read, readlink, rt_sigaction, rt_sigprocmask, set_robust_list, set_tid_address, socket, stat, statx, writeFrom what I can tell, all of these are allowed by the default seccomp profile of Docker 18.06, only the rule for
arch_prctlis listed separately. I also verified that Docker has no problems accessing the seccomp file, which could've been a cause for my problem.Perhaps I should do a kernel update, as it currently is my last idea to fix this issue (without using
--security-opt seccomp=unconfined).
21/25