Chrome under Docker: CAP_SYS_ADMIN vs privileged?

english
#1

I am running chromedriver + chrome inside Docker in my test environment.

Everything was working fine until latest CoreOS upgrade.

These are the versions that seem to work:

VERSION=1185.5.0
VERSION_ID=1185.5.0
BUILD_ID=2016-12-07-0937

And this a newer version that causes chrome to coredump:

VERSION=1235.4.0
VERSION_ID=1235.4.0
BUILD_ID=2017-01-04-0450

Looking at changes, it seems docker was upgraded from 1.11.x to 1.12.x, which broke setns() call inside container. setns() is used by Chrome for creating a namespaces.

This are the example outputs:

jsosic-coreos-test-20161207 ~ # docker --version
Docker version 1.11.2, build bac3bae

From inside one container on this box:

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome
[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

This is how the new version broke it:

jsosic-coreos-test-2017-01-04 ~ # docker --version
Docker version 1.12.3, build 34a2ead

[root@13ab34c36c82 /]# /opt/google/chrome/chrome
Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

What I have found out is that if I start the container with either --cap-add=SYS_ADMIN or --privileged - Chrome works as expected.

What is the difference between those two switches? What capabilities are enabled by --privileged?

And, can I allow setns() inside container without compromising security?

#2

AFAICS, the documentation suggests granting the capabilities needed for a container, rather than using the --privileged switch. Running in privileged mode seems to grant the container all capabilities (exactly which those are is listed in the first URL, provided that the docs are up to date).

In short, I'd say that --cap-add=SYS_ADMIN grants a smaller subset of capabilities to the container, compared to the --privileged switch. Event the examples in the Docker documentation (first URL) seem to prefer just adding the SYS_ADMIN or NET_ADMIN capability where needed.

#3

One difference is that --privileged mounts /dev and /sys as RW, where as SYS_ADMIN mounts them as RO. This means that a privileged container has full access to devices on the system. SYS_ADMIN doesn't give you that.

#4

Thanks for this. I made an issue, using a lot of your stuff: Allow setns() in container, or add flag to allow it specifically · Issue #496 · docker/for-linux · GitHub I think it ought to get fixed

#5

I am nearly 2 years too late, but there is a much better and safer solution in the ticket above if you are still interested.

#6

If the original poster doesn’t update the answer (he doesn’t seem active on SO at all), let me know if you would be available to accept a different one. I wasted hours on this, I can only imagine how many hours we will save other people.