Enhancement and design discussion

[mviereck]

Coming from #109 and #111

@mviereck wrote: Currently containers are allowed to access the internet per default. It can be forbidden with --no-internet. I consider to change the default for next major release 6.0. Internet access would be forbidden as default and could be enabled with -I, --internet. I assume this will be an unpopular default. But it would fit the sandbox target. What do you think?

@1138-4EB wrote: I agree with both points: it will be an unpopular default and it fits the sandbox target. In order to work around the popularity issue, and related to this comment about --user=RETAIN, I think it would be sensible to add a -D, --DOCKER-DEFAULTS option. This option would be just an alias of --user=RETAIN --cap-default -I, plus any other option that fits the purpose. This would fit three targets:

• Users that want to run GUI apps/desktops each in it's own container with sane defaults (x11docker defaults).
• Users that want to just add GUI capability to their existing scripts/toolchains which user docker run.
• Users that use docker and want to learn how they can improve their current toolchains, but they don't need x11docker nor want they to rely in a external script. Checking -D can be useful for this group, even if they don't actually use x11docker.

Overall, I think that there is very interesting know-how in this project, and it might be more popular if the entry barrier could be slightly reduced for active docker users.

---

@1138-4EB wrote in #111: I meant that, with --user=RETAIN some features are disabled, which are defaults from a docker user's point of view. So, with RETAIN you keep the same user as you would with docker run, but you cannot do the same things inside the container. E.g., I might want to use --user=RETAIN because there is a user in the image which is not root but which has admin privileges inside the container. However, I might not apt update. So, I think it is worth a note.

[mviereck]

I think it would be sensible to add a -D, --DOCKER-DEFAULTS option.

Instead of a new option I consider to give a note at a prominent place in x11docker --help and README.md:

Note that some applications might behave different than with a regular
docker run command due to security restrictions set by x11docker.
Unrestricted setup is possible with: --user=root --cap-default --clipboard

[--internet] I agree with both points: it will be an unpopular default and it fits the sandbox target.

There is already a note about --no-internet in the security paragraph of README.md. Maybe I should drop the --internet idea to keep popularity. Users that are really interested in security and sandboxing will read it.

Overall, I think that there is very interesting know-how in this project, and it might be more popular if the entry barrier could be slightly reduced for active docker users.

Thanks :-) I am a bit blind for the barriers. Maybe you can point me on them and I write a "Beginner's introduction".

[eine]

Instead of a new option I consider to give a note at a prominent place in x11docker --help and README.md:

I think that it'd be good to have both. But the documentation/note alone is ok too.

Note that some applications might behave different than with a regular
docker run command due to security restrictions set by x11docker.
Unrestricted setup is possible with: --user=root --cap-default --clipboard

Is --cap-default required with --user-root? Or is it a typo and you mean --user=RETAIN?

There is already a note about --no-internet in the security paragraph of README.md. Maybe I should drop the --internet idea to keep popularity. Users that are really interested in security and sandboxing will read it.

What about adding a short note/remainder? E.g. This container has internet access. Could you use --no-internet for this task? See section about security in the README.

I am a bit blind for the barriers. Maybe you can point me on them and I write a "Beginner's introduction".

Active docker users are expected to feel comfortable with CLI tools, because that's how you use docker most of the time. They should also be able to manage themselves in the directory tree of either GNU/Linux and perform common tasks such as cp, mv, tar, chmod, etc. Since most of the uses of docker involve orchestration of multiple containers, they might also know something about networks. But they probably know little to nothing about what an application requires for a GUI to be drawn on a X server. Even if they fought with some driver graphics, or if they wrote some app with a framework, the details are unknown.

So, I'd start with:

• What's an X server?
  • A service that listens on a port. The port can be a socket, a tcp port, etc. Due to security issues, it is suggested to be a socket.
• How does an X server handle security?
  • It can be disabled.
  • It can be done through hostnames.
  • The standard approach is to use a cookie. Who creates it? How do you create it?
• What does a container need for apps inside it to be drawn in a X server?
  • Libraries/dependencies to be able to talk to an X server. These are normally required by the GUI apps.
  • The socket/port.
  • The display number.
  • (optional) The authorization cookie.
• Who are all the others in this party?
  • xvfb
  • A virtual framebuffer. It is an X server that is not connected to any real (hardware) display. I.e., the content is saved in memory, but no screen shows it.
  • Xorg
  • This is THE X server. Default on most unix distros.
  • VcXsrv, Cygwin/X, Xmingw...
  • Diferent implementations/builds of a Xorg server for Windows.
  • Wayland
  • Is a different kind of window server, which is mean't to be a replacement for Xorg. It is not yet adopted by many distros. Only available on GNU/Linux.
  • Since not all the apps support it, a compatibility layer exists: xwayland.
  • Xephyr
  • Creates an X server as a window of an existing X server. It's a kind of inception. We might say that it is conceptually similar to docker-in-docker, but this is X-in-X.
  • xpra
  • Is both a service that makes a bridge between an X server and it's own protocol, and a client that makes a bridge between it's protocol and an window server.
  • Unlike the other tools, this is designed with remote access in mind. Precisely, it is also known as screen for X11, because it allows a client to attach and detach from running programs.
    • It supports many connection modes: TCP, SSH, SSL, WS, WSS... It is usable over reasonably slow links and does its best to adapt to changing network bandwidth constraints.
  • Is it worth mentioning nxagent, weston and kwin here?
  • And what about audio, webcams, printers, etc.?
  • The procedure is similar to sharing an X server: most of them require sharing one or more directories with the host, installing some libraries in the containers, and passing some parameters. See details at...

And that's it. I wouldn't make it any longer than it is now. Just reword it in paragraphs and add lots of links to the pages of the projects, to man pages, to the wiki and to any reference that suits the purpose.

Then, if you wish to add a guide as an extension to the introduction. I would start from configurations with less dependecies/setup time, and slowly add complexity. You can take the existing examples as a reference:

• Which are the minimum requirements to execute x11docker x11docker/xfce xfce4-terminal?
  • How do I install x11docker?
  • x11docker IS A SCRIPT. On big shiny capital letters. That's one of the impresive features of this project. No python runtime, no nodejs, no compiled artifacts... Just a very carefully crafted 7k line long script.
  • However, we suggest to execute curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker | bash -s -- --update, in order to install the GUI/Launcher.
  • No dependencies besides an X server and a bash shell are required in order to use --hostdisplay and --xorg. What's the difference between these two modes?
  • Nevertheless, it is recommended to have these tools on the host: xauth, xclip, xrandr, and xdpyinfo.
  • However, in order to improve the security/isolation, installing either xpra or xephyr is recommended. These allow modes --xpra and --xephyr, respectively. What's the difference between these two modes? Note: xpra on windows currently only available in cygwin, soon in MSYS, or inside a container; xephyr not available on windows.
  • xpra can be installed in a container, so that no additional dependencies are required on the host.
• Some apps can benefit from GPU acceleration. For example x11docker --gpu x11docker/xfce glxgears.
  • Which are the minimum requirements to use --gpu? weston and/or Xwayland are required. xdotool is also suggested. These provide modes --xpra-xwayland, --weston-xwayland, --weston, --xwayland, --wayland.
  • Discuss the differences between the modes.

Last, a third chapter could be about docker defaults, x11docker defaults and unavoidable flaws.

[mviereck]

I have adapted some suggestions in the documentation. Thank you for giving a possible structure.

However, overall this would be a major background documentation, and I feel I won't do this task for a long time. I'll close for now and maybe come back to this in future.