Chrome under Docker: CAP_SYS_ADMIN vs privileged? [closed]How to control Chrome in a network environmentGoogle Chrome Language TranslateHow can I override CMD when running a docker image?Kernel Tuning with Privileged Docker ContainerSSL_VERSION_OR_CIPHER_MISMATCH in chrome 42Removing Docker data volumes?How to remove an image tag in Docker without removing the image itself?Chrome Master_Preference AllowPopUpsDocker Port Forwarding and Privileged Flag not workingRestart docker container in privileged mode
Similarity score: Can Sklearn SVR predict values greater than 1 and less than 0?
What can I do with a research project that is my university’s intellectual property?
Should the party get XP for a monster they never attacked?
Excluding a rectangular region from an image in FITS
How can I get my left hand to sound legato when I'm leaping?
How to maintain a closed environment for one person for a long period of time
Do I have to explain the mechanical superiority of the player-character within the fiction of the game?
Can Ogre clerics use Purify Food and Drink on humanoid characters?
How does DC work with natural 20?
Boss wants someone else to lead a project based on the idea I presented to him
Hit the Bulls Eye with T in the Center
Prime sieve in Python
Count All Possible Unique Combinations of Letters in a Word
Encounter design and XP thresholds
Am I legally required to provide a (GPL licensed) source code even after a project is abandoned?
Can humans ever directly see a few photons at a time? Can a human see a single photon?
Primes and SemiPrimes in Binary
Why do all the teams that I have worked with always finish a sprint without completion of all the stories?
What does it mean to not be able to take the derivative of a function multiple times?
What's currently blocking the construction of the wall between Mexico and the US?
Why isn't my calculation that we should be able to see the sun well beyond the observable universe valid?
What is the meaning of "понаехать"?
Is it illegal to withhold someone's passport and green card in California?
How many people are necessary to maintain modern civilisation?
Chrome under Docker: CAP_SYS_ADMIN vs privileged? [closed]
How to control Chrome in a network environmentGoogle Chrome Language TranslateHow can I override CMD when running a docker image?Kernel Tuning with Privileged Docker ContainerSSL_VERSION_OR_CIPHER_MISMATCH in chrome 42Removing Docker data volumes?How to remove an image tag in Docker without removing the image itself?Chrome Master_Preference AllowPopUpsDocker Port Forwarding and Privileged Flag not workingRestart docker container in privileged mode
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
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?
permissions docker chrome namespaces
closed as off-topic by womble♦ Jun 5 at 2:03
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow." – womble
add a comment |
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?
permissions docker chrome namespaces
closed as off-topic by womble♦ Jun 5 at 2:03
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow." – womble
Thanks 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
Nov 22 '18 at 1:54
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.
– Merc
Nov 23 '18 at 3:33
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.
– Merc
Nov 23 '18 at 3:35
add a comment |
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?
permissions docker chrome namespaces
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?
permissions docker chrome namespaces
permissions docker chrome namespaces
asked Jan 7 '17 at 13:13
Jakov SosicJakov Sosic
4,30921628
4,30921628
closed as off-topic by womble♦ Jun 5 at 2:03
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow." – womble
closed as off-topic by womble♦ Jun 5 at 2:03
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow." – womble
Thanks 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
Nov 22 '18 at 1:54
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.
– Merc
Nov 23 '18 at 3:33
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.
– Merc
Nov 23 '18 at 3:35
add a comment |
Thanks 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
Nov 22 '18 at 1:54
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.
– Merc
Nov 23 '18 at 3:33
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.
– Merc
Nov 23 '18 at 3:35
Thanks 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
Nov 22 '18 at 1:54
Thanks 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
Nov 22 '18 at 1:54
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.
– Merc
Nov 23 '18 at 3:33
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.
– Merc
Nov 23 '18 at 3:33
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.
– Merc
Nov 23 '18 at 3:35
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.
– Merc
Nov 23 '18 at 3:35
add a comment |
2 Answers
2
active
oldest
votes
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.
Thanks,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 :)
– Jakov Sosic
Jan 8 '17 at 14:42
Just 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.
– Merc
Nov 23 '18 at 3:34
add a comment |
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.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
Thanks,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 :)
– Jakov Sosic
Jan 8 '17 at 14:42
Just 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.
– Merc
Nov 23 '18 at 3:34
add a comment |
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.
Thanks,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 :)
– Jakov Sosic
Jan 8 '17 at 14:42
Just 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.
– Merc
Nov 23 '18 at 3:34
add a comment |
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.
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.
edited May 23 '17 at 12:41
Community♦
1
1
answered Jan 8 '17 at 11:29
ivukivuk
1764
1764
Thanks,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 :)
– Jakov Sosic
Jan 8 '17 at 14:42
Just 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.
– Merc
Nov 23 '18 at 3:34
add a comment |
Thanks,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 :)
– Jakov Sosic
Jan 8 '17 at 14:42
Just 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.
– Merc
Nov 23 '18 at 3:34
Thanks,
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 :)– Jakov Sosic
Jan 8 '17 at 14:42
Thanks,
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 :)– Jakov Sosic
Jan 8 '17 at 14:42
Just 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.
– Merc
Nov 23 '18 at 3:34
Just 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.
– Merc
Nov 23 '18 at 3:34
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Jun 4 at 20:20
mel1990mel1990
111
111
add a comment |
add a comment |
Thanks 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
Nov 22 '18 at 1:54
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.
– Merc
Nov 23 '18 at 3:33
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.
– Merc
Nov 23 '18 at 3:35