Issue with ~/.cache permission 700

[phil294]

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 with Xvfb installed.

x11docker -v --hostdisplay xorilog/telegram --> https://pastebin.com/Hvvq9ECY

Looks pretty normal to me, except for

/bin/sh: 0: Can't open /x11docker/containerrootrc

and 4 minutes of

Waiting since 164s for container setup to be ready

and, when it finally finishes,

==> /home/phi/.cache/x11docker/xorilog-telegram-340e4f8713bb4aae8f0e01dda0b4d312/share/stderr <==
QXcbConnection: Could not connect to display :0.0

mkdir: cannot create directory '/fakehome': Permission denied

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.

[mviereck]

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?

[phil294]

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..?

[phil294]

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.

[phil294]

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?

[mviereck]

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.

[mviereck]

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.

[mviereck]

I've made an update that sets chmod 666 on all x11docker cache files. Please try out if that helps.

[phil294]

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. :-)

[mviereck]

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. :-)

:-)

[phil294]

Works!
Thanks.