Closed phil294 closed 5 years ago
Thanks for reporting!
Currently I am a bit confused and not sure what is going on. The same command works well here. (Debian 10, Xfce).
You already found a core error message:
/bin/sh: 0: Can't open /x11docker/containerrootrc
However, the file is created and should be available in container.
Maybe it is some sort of privilege issue. Can you try with --cap-default
, please?
With --cap-default
, I can finally see the program! (verbose log) Great.
Which permissions should I check? Shouldnt it not matter anyways, because it is all containerized..?
Attaching to the idle (non-visible / waiting / non-cap-default) container and executing
I have no name!@e8030aaa56d8:/x11docker$ ls -la /x11docker
results in
total 776
drwxr-x--- 2 1000 1000 4096 Feb 25 18:26 .
drwxr-xr-x 1 root root 4096 Feb 25 18:26 ..
-rw-r--r-- 1 1000 1000 53 Feb 25 18:26 Xclientcookie
-rw-r----- 1 1000 1000 2708 Feb 25 18:26 container.CMD.sh
-rw-r----- 1 1000 1000 4 Feb 25 18:26 container.user
-rw-r----- 1 1000 1000 4639 Feb 25 18:26 containerrootrc
-rw-r----- 1 1000 1000 0 Feb 25 18:26 environment
-rw-r----- 1 1000 1000 0 Feb 25 18:26 journalctl.log
prw-rw-rw- 1 1000 1000 0 Feb 25 18:27 message.fifo
-rw-rw-rw- 1 1000 1000 0 Feb 25 18:26 stderr
-rw-rw-rw- 1 1000 1000 0 Feb 25 18:26 stdout
-rw-r----- 1 1000 1000 0 Feb 25 18:26 timetosaygoodbye
prw-r----- 1 1000 1000 0 Feb 25 18:26 timetosaygoodbye.fifo
-rwxr-xr-x 1 root root 712672 Feb 11 23:55 tini
-rw-r----- 1 1000 1000 50646 Feb 25 18:27 x11docker.log
and containerrootrc
is cat-able.
Another answer, hopefully the last one:
running with --user=root
also fixed it. Yey. If I understand correctly, this would only be a security risk in combination with docker vulnerabilities so thats ok with me.
Most files in ~
including .cache
have permissions set to 700
on my system, because they are not the business of any other user besides me. I think this is the sanest setting. Might this be the issue here? Is x11docker relying on group/other permissions in my home folder?
With
--cap-default
, I can finally see the program! (verbose log) Great.
Good!
Shouldnt it not matter anyways, because it is all containerized..?
--cap-default
allows default docker settings. They are not bad, but x11docker follows the 'least privilege needed' concept. Containers are somewhat isolated, but nothing in IT should be considered secure.
containerrootrc is cat-able.
So the question is: why sh
cannot execute it? Why is it possible with --cap-default
?
Is your host home mounted with noexec
? However, --cap-default
would not make a difference in that case.
Which permissions should I check?
Currently I am not sure. Meanwhile I did a check in an archlinux VM and could not reproduce the issue. I also know of at least one archlinux user who uses x11docker on a daily base and reports every issue.
Some possible checks:
x11docker -v --hostdisplay -- --cap-add ALL -- xorilog/telegram
x11docker -v --hostdisplay --cap-default -- --cap-drop ALL -- xorilog/telegram
running with --user=root also fixed it.
That includes --cap-default
Most files in ~ including .cache have permissions set to 700 on my system, because they are not the business of any other user besides me. I think this is the sanest setting. Might this be the issue here? Is x11docker relying on group/other permissions in my home folder?
That might be the reason. Let me think about it.
Probably I found it due to the 700 access restriction. From docker documentation:
DAC_OVERRIDE Bypass file read, write, and execute permission checks.
Please try:
x11docker -v --hostdisplay -- --cap-add DAC_OVERRIDE -- xorilog/telegram
DAC_OVERRIDE
allows access for root to files not owned by root.
containerrootrc
is owned by the host user with 700
and root cannot access it without this capability.
Maybe it helps if x11docker sets 666
on containerrootrc. However, I am not sure if that supersedes the parent folder permissions.
I've made an update that sets chmod 666
on all x11docker cache files. Please try out if that helps.
oh boi, you are quick. Makes sense what you are saying, thanks.
--cap-add DAC_OVERRIDE
does the trick!
Running with your latest commit alone does not work (tested). Since .cache
itself is missing execution rights for others, they cannot read the files inside. So the chmod
would also need to modify all parent dirs which is a bad idea. I am confused root could ever read anything then if it was dependent on the others-rights, but you seem to know what you are doing, so whatever.
also know of at least one archlinux user who uses x11docker on a daily base and reports every issue.
Now you know two. :-)
I did a workaround: x11docker copies containerrootrc
to /tmp
in container before executing it with sh
. Hopefully it works now without --cap-add DAC_OVERRIDE
. Please try out.
Now you know two. :-)
:-)
Works! Thanks.
I am sorry I cannot make this more specific: Trying to run anything in seamless mode, that is, wihtout
Xephyr
, but nothing visible is happening. Same with--hostdisplay
or--xpra
or--nxagent
, both installed. The below output is withXvfb
installed.x11docker -v --hostdisplay xorilog/telegram
--> https://pastebin.com/Hvvq9ECYLooks pretty normal to me, except for
and 4 minutes of
and, when it finally finishes,
System: Arch Linux 64 Linux 4.20 XFCE4 Xfwm
Any help will be appreciated. Thanks for this project @mviereck: Even though I cannot see anything, it looks awesome :D
edit: without
Xvfb
, the output contains/usr/lib/Xorg.wrap: Only console users are allowed to run the X server
but that was fixed by adding it.