you need to
- Set the
$DISPLAY variable correctly,
- give access to the
~/.Xauthority file
- share the socket within the
/tmp/.X11-unix directory
Note that once you share your X server with a different client, it's basically the same as running the program as your own user, security-wise: the client can observe the keyboard, take screen shots, synthesize key presses, and I wouldn't be surprised if some lesser-used functionality in the X11 protocol (loading textures? Fonts?) could be abused as remote file reader. Not an expert in the X11 protocol, though.
Since the isolation is super weak, anyway, you could also be less complicated in how you restrict access to your home directory: Containers.
Linux has namespaces, and technologies like docker, kubernetes, snaps and so on depend on that. What you can do is start a process, as a normal user, and give that process a complete own view of the user and file system landscape – one without your home directory.
Podman is one of these technologies, and it's available on debian, IIRC. Installing it should be as straightforward as possible:
sudo apt install -y podman
Then, you should just be able to run containers:
podman run -it --rm debian:sid
# | | | |
# +--------------- Run subcommand: run a container
# | | |
# +----------- interactive, i.e., assign a virtual terminal,
# | | so you can see and type into an interactive session
# | |
# +------- Remove the container after you're done - no data survives,
# | if it's only in the container. Of course, things on
# | volumes specified using the -v source_path:destination
# | persist, since they are "outside".
# |
# +-- name:tag is the way to specify what
# container you want to fetch in which version
To run something graphical, you need to allow the things mentioned above, and tell SELinux you're up to things you promise are OK:
podman run -e DISPLAY=$DISPLAY \
-v /tmp/.X11-unix:/tmp/.X11-unix:Z \
-v ~/.Xauthority:/root/.Xauthority:Z \
--security-opt label=type:container_runtime_t \
-it --rm fedora:35
# ||||
# +---- -e INSIDE=OUTSIDE set an env variable INSIDE inside the
# ||| container to the value OUTSIDE
# |||
# +--- -v SOURCE:DEST[:permissions]
# || SOURCE directory or file appears under DEST within
# || container; :Z means that the podman-running users'
# || permissions are translated to root permissions inside.
# || Here, mount the host's X11 socket directory at the same place
# ||
# +-- -v SOURCE:DEST[:permissions] again
# | Here, mount the podman-running user's ~/.Xauthority
# | as /root/.Xauthority owned by root.
# |
# +- --rm -it: see above
[root@4da385540218 /]#
see how you're suddenly root inside a container that you've started yourself – as non-root!
We can now install vscode into this container, sharing your folder ~/sourcecode as /sourcecode in the container, and using that as user data directory for vscode:
podman run -e DISPLAY=$DISPLAY \
-v /tmp/.X11-unix:/tmp/.X11-unix:Z \
-v ~/.Xauthority:/root/.Xauthority:Z \
--security-opt label=type:container_runtime_t \
-v ~/sourcecode:/sourcecode:Z \
-it --rm fedora:35
[root@4da385540218 /]#
rpm --import https://packages.microsoft.com/keys/microsoft.asc
[root@4da385540218 /]#
echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/vscode.repo
[root@4da385540218 /]#
dnf --refresh update -y
[root@4da385540218 /]#
dnf install -y code
[root@4da385540218 /]#
code --user-data-dir /sourcecode/ --no-sandbox
