Chrome under Docker: CAP_SYS_ADMIN vs privileged?
Solution 1
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.
Solution 2
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.
Related videos on Youtube
Clément Perroud
Unix/Linux enthusiasts. Hello, I'm Jakov. I currently work as a Systems Engineer I'm very passionate in Open Source Software and Unices (Linux, *BSD), networking and development. As a Myers-Briggs INFJ I insist on high quality and am purist at most times. I hate fast hacks and like the systems to be set up as cleanly as possible (everything packaged up in OS native packages, services deployed and configured with configuration management, etc).
Updated on September 18, 2022Comments
-
Clément Perroud almost 2 years
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?-
Merc over 5 yearsThanks for this. I made an issue, using a lot of your stuff: github.com/docker/for-linux/issues/496 I think it ought to get fixed
-
Merc over 5 yearsI am nearly 2 years too late, but there is a much better and safer solution in the ticket above if you are still interested.
-
-
Clément Perroud over 7 yearsThanks,
exec_linux.go
helped. I tried cloning docker repo to grep through it but since it took me couple of hours I just forgot about it :) -
Merc over 5 yearsJust to run Chrome, there is a much better solution listed here: github.com/docker/for-linux/issues/496#issuecomment-441149510 I think it would be very beneficial to update the answer so that people do what I explain in that very comment. Please let me know if you agree.