Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with ~/.cache permission 700 #131

Closed
phil294 opened this issue Feb 24, 2019 · 10 comments
Closed

Issue with ~/.cache permission 700 #131

phil294 opened this issue Feb 24, 2019 · 10 comments
Labels

Comments

@phil294
Copy link

phil294 commented Feb 24, 2019

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
Copy link
Owner

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
Copy link
Author

phil294 commented Feb 25, 2019

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
Copy link
Author

phil294 commented Feb 25, 2019

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
Copy link
Author

phil294 commented Feb 25, 2019

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
Copy link
Owner

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
Copy link
Owner

mviereck commented Feb 25, 2019

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 added a commit that referenced this issue Feb 25, 2019
@mviereck
Copy link
Owner

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

@mviereck mviereck added the bug label Feb 25, 2019
@phil294
Copy link
Author

phil294 commented Feb 25, 2019

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
Copy link
Owner

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
Copy link
Author

phil294 commented Feb 25, 2019

Works!
Thanks.

@phil294 phil294 closed this as completed Feb 25, 2019
@mviereck mviereck changed the title Seemless mode does nothing regardless of options Issue with ~/.cache permission 700 Mar 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants