Now the container is predominantly isolated with only read and write access to X authentication and socket file. Xauth nlist $DISPLAY | sed -e 's/^./ffff/' | xauth -f $XAUTH nmerge. Here is an example of a run command doing just this: The next step is to make a X authentication file with proper permissions and mount this to a volume for the container to use. You may need to change the number 1000 for the uid and gid to mach that of your host's user. This is an example of what you may need to add to the docker file, or similarly run and commit in the container:Įcho "$USERNAME:$USERNAME" | chpasswd & \Įcho "$USERNAME ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/$USERNAME & \ We can do this with some modifications to the original image by creating a user with uid and gid matching that of the host user. There is another way to emulate the same technique with the previous method but in a more isolated manner. So by means of convenience and security, one can lose some aspects of isolation, and other useful properties of repeatability, reducibility, and portability if not careful. This last bit how ever removes quite a few layers of separation between what runs in the container and the environment of the host, and is thus not as isolated.
#Tigervnc docker password
This allows you access to local config file for your local user, maintaining the same username, password and file permissions. You could chose to go one step further by mounting your own home directory into the container. Some applications expect a home directory for the user in order to save and read configuration files, so if you attempt to use them without such a directory existing in the container's filesystem, you may receive warnings or errors. volume="/etc/sudoers.d:/etc/sudoers.d:ro" \ Log in with your uid:gid and add some shared volumes to be able to really use your local account in the container docker run -it \
This involves mounting additional directories and becoming yourself in the container: This will add the container's hostname to the local family's list of permitted names.Īnother way is to use your own user's credentials to access the display server. Xhost +local:`docker inspect -format='' $containerId` The first is to runĪfter you are finished using the containerized GUI, this will return the access controls that were disabled with the previous command.Ī better option is opening up xhost only to the specific system that you want, for instance if you are running a container on the local host's docker daemon with container's ID stored to the shell variable containerId If you are concerned about this (as you should be), you have at least two options.
Xhost +local:root # for the lazy and reckless So with a little effort, someone could display something on your screen, capture user input, in addition to making it easier to exploit other vulnerabilities that might exist in X. This is not the safest way however, as you then compromise the access control to X server on your host. We can then adjust the permissions the X server host. This will fail at first and look something like this, but that's ok: volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \Ībove, we made the container's processes interactive, forwarded our DISPLAY environment variable, mounted a volume for the X11 unix socket, and recorded the container's ID. The simple way is expose your xhost so that container can render to the correct display by reading and writing though the X11 unix socket. The fourth is isolated, works remotely, but is slow.
#Tigervnc docker portable
The third is isolated, but not as portable.The first listed is simple, but unsecure.A brief description and tradeoffs for each method below: There are several ways one can connect a container to a host's X server for display. X server is a windowing system for bitmap displays, common on linux operating systems. And it can also pass through PulseAudio with -pulse.
It can also pass through your user using -user and mount your home directory using -home.
#Tigervnc docker driver
If you have an nvidia driver and need graphics acceleration you can run it with -x11 as an option to enable the X server in the container. Rocker is a tools which will help you run docker containers with hardware acceleration.
0 kommentar(er)
