not isolated xephyr + openbox

[hfont]

As I have openbox installed, when I run:

x11docker --xephyr --homedir [home] -- -v [path]:[path] -- [image]

It uses openbox but strangely everything from the host seems to be shared, why?

The image was constructed without CMD and entrypoint

seems to be running host openbox on the display created by xephyr

x11docker 5.6.0

[mviereck]

Thanks for pointing on this, it is indeed not obvious what is going on.

I have changed the message shown by x11docker:

x11docker note: Using host window manager openbox --sm-disable
  If it is a window manager with a context menu like e. g. openbox,
  you are able to run host applications in the new X server.
  Don't be confused, container applications should not be able to abuse this.
  X extension XTEST is disabled to avoid remote host control with xdotool
  through emulated keypresses or mouse clicks.
  The clipboard within X server --xephyr will be shared, though.
  Also the container can move or close other windows within this X server,
  and can run a keylogger for keypresses within this X server.

Is this a comprehensive explanation? The host applications are not shared with the container. They can access everything on the host, but container applications can't.

[hfont]

So I understood the openbox executed by the host using the display created by xephyr

This means that if it is for Terminals > Xterm it will open a child process of openbox

I can preview, paste, copy things from the host

From what you said an application inside the container can not do this I did not check why not.

This is confusing by the script proposal

I believe window manager should be installed inside the container and not use the host's

Or at least prevent x11docker from automatically using the host window manager, so that the person will be aware sharing the host window manager within the display of the container

You respond quickly, thank you.

[mviereck]

I believe window manager should be installed inside the container and not use the host's

This is possible as well. In general, x11docker can run in single application mode (default) or in desktop mode (option --desktop).

For example, if you run x11docker --desktop x11docker/xfce, x11docker will run Xephyr, and the container will run an Xfce desktop with its own window manager xfwm4.

For single applications in seamless mode x11docker recommends to install xpra or nxagent on host. Xephyr with a host window manager is a fallback for single applications if x11docker finds only Xephyr, but neither xpra or nxagent. A window manager in Xephyr is needed, otherwise single application cannot be moved or resized and are rather useless.

Or at least prevent x11docker from automatically using the host window manager, so that the person will be aware (even if limited) sharing the host window manager within the display of the container

My intention was to provide a usable default setup without the need of additional setup to be done by the user. Alternatively, x11docker could run without a window manager and show a note that the user has to set option --wm itself.

It can be reasoned which attempt is the better one.

• You are right that this can be seen as a mismatch to the proposal. This way host applications and container application run side by side, and there is a limited communication between them. Although it is limited, it is not a full isolation.
• On the other hand, I think that the setup with disabled extension XTEST is ok from a security point of view. Also, Xephyr with a host window manager is a fallback way only. (x11docker prefers --xpra and --nxagent for single applications and shows a note if it falls back to --xephyr with a host window manager.)

---

To address your valid point of view, and also to avoid the dependency on a window manager in the image, I consider to create a standalone minimal image that contains a window manager only and could be used automatically.

[mviereck]

I have created a new image x11docker/openbox. x11docker will use this one by default to provide a window manager if the image is available. (The context menu of openbox is disabled. Even if it would work, it would only give access to the openbox container.)

If image x11docker/openbox is not available locally, a note is shown and a host window manager is used. It is possible to enforce a host window manager with --wm=host or --wm=COMMAND.

You can run x11docker --update-master to get the latest beta version including this fix.

[mviereck]

The new implementation of --wm is considered to be complete. From x11docker --help:

 -w, --wm [=ARG]       Provide a window manager for container applications
                       for nested X server options like --xephyr.
                       If available, image x11docker/openbox will be used,
                       otherwise x11docker looks for a host window manager.
                       Possible ARG:
                         host: Enforce autodetection of a host window manager.
                         COMMAND: COMMAND can be a desired host window manager.
                         IMAGE: IMAGE can be a local docker image with a WM.
                         none: Run without a window manager. Same as --desktop.

If available, x11docker uses image x11docker/openbox, otherwise it falls back to use a host window manager and shows a note. Other images can be specified, too, e.g. --wm=x11docker/lxde.

If you have any thoughts on this, please let me know.