mviereck / x11docker

Run GUI applications and desktops in docker and podman containers. Focus on security.
MIT License
5.62k stars 378 forks source link

--exe --user sets wrong user #437

Closed phil294 closed 2 years ago

phil294 commented 2 years ago

I've been using x11docker for a substantial time now, but today I learned in a SE post of yours that it's possible to use x11docker as a proxy to nxagent without docker which is great. I tried to do that with VSCodium:

sudo x11docker --user another_user --nxagent --exe -- vscodium --verbose

According to the integrated terminal, this correctly sets the user working dir to /home/another_user/, but whoami, $UID etc. show that the current user is not another_user, but actually the normal user (the one you're logged into your regular desktop environment). Is this a bug?

OS: Manjaro 21.2.6 Qonos
Kernel: x86_64 Linux 5.4.188-1-MANJARO
Shell: bash 5.1.16
DE: Xfce4
WM: Xfwm4
mviereck commented 2 years ago

Thank you for the report! There has been some issues with option --exe that are fixed meanwhile. In recent x11docker versions (current stable is 7.1.4) --exe does no longer support option --user and prints an error message in that case. (btw., --exe is deprecated and replaced by --backend=host). Which x11docker version do you use? There is an AUR package of x11docker that is up to date, I assume it works for Manjaro, too.

If you have a major use case for --user with host applications, I might reintroduce it.

phil294 commented 2 years ago

Oh, no, sorry! I accidentally used the outdated version 7.0.1, thought it was the up to date one. So this issue is resolved per se.

If you have a major use case for --user with host applications, I might reintroduce it.

The same reason for why you might want to use --backend=docker: isolation. I thought I could run some programs with limited permissions, that is, as a separate user without access to foreign home folders. In this example, I simply ran some sandboxing tests with VSCode(ium): If --user another_user had worked, then any potentially malicious extension inside VSCode could not be accessing my local files, as appropriately set user permissions pose strong protection against that, as far as I now.

Skipping nxagent/x11docker altogether works too of course, but that misses x11 isolation.

I did use --backend=host to skip the involvement of Docker which would then simply not have been necessary. But other than that, there's not much to be gained from it, so I am not sure if there is a point in reintroducing it.

Thank you! Please feel free to close this

mviereck commented 2 years ago

There is a similar option --hostuser to achieve the same as one would expect with --user. I've made some fixes, now your desired setup works. E.g.:

sudo x11docker --hostuser another_user --nxagent --backend=host -- vscodium --verbose

With option --user x11docker prints a message with a hint to use --hostuser. You can install the master/beta version with x11docker --update-master.

I thought I could run some programs with limited permissions, that is, as a separate user without access to foreign home folders.

That is a reasonable use case. Access to home folders of other users depends on the configuration of the system. Some systems allow read-only access to HOME of other users.

I have the impression that only very few users use --backend=host so I rarely check and work at it.


Thank you very much for your donation! You are my very first sponsor since I've enabled the sponsor button some weeks ago.

phil294 commented 2 years ago

Yes!! Works perfectly now! Thanks a bunch.

I think backend=host is primarily handy for a standard cli to different xserver tools. Setting up nxagent by hand or getting basic things such as clipboard support inside Xephyr is quite a struggle, but it's a breeze with x11docker.