New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is `-v /var/run/docker.sock:/var/run/docker.sock` a ticking time bomb? #21109

Open
ibuildthecloud opened this Issue Mar 11, 2016 · 14 comments

Comments

Projects
None yet
9 participants
@ibuildthecloud
Copy link
Contributor

ibuildthecloud commented Mar 11, 2016

So..... -v /var/run/docker.sock:/var/run/docker.sock is super common, and I'm very guilty of this. For anyone who has dealt with bind mounting UNIX sockets finds out really quickly that you can't bind mount the socket itself, but instead you must bind mount the directory containing the socket. This is because the listening process will delete and recreate the socket so if you bind mount a socket you hold a reference to something that is possibly not used. BUT... /var/run/docker.sock is special because if that file is deleted and recreated, well, your container is too. With containerd integration #2658 is supposed to be fixed, but what happens to /var/run/docker.sock on daemon restart. How will this be addressed.

@jessfraz

This comment has been minimized.

Copy link
Contributor

jessfraz commented Mar 11, 2016

only you 👏 nice find

@phemmer

This comment has been minimized.

Copy link
Contributor

phemmer commented Mar 11, 2016

This might be nice to fix for other uses as well. Another common case of binding sockets is -v /dev/log:/dev/log, which fails if the syslog daemon restarts on the host.
There are only 2 solution I can think of.

  1. The docker daemon were to proxy the socket instead of bind mounting it. We could do this, and make it transparent by just having docker check if the -v argument is a socket, and if so, implement the proxy.
  2. The docker daemon does a bind mount, but monitors the socket on the host. If it gets recreated, it recreates the mount. This is potentially problematic though as there are edge cases where this wouldn't behave right (though the cases I can think of are really rare).
@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Mar 11, 2016

@phemmer Recreating the mount won't really work since the container won't see the updated mount info.

@bboreham

This comment has been minimized.

Copy link
Contributor

bboreham commented Mar 11, 2016

Or you could add a way to declare a container as "needs to interact with host Docker", then the socket is provided without any -v flags. Related to #20363, perhaps.

@phemmer

This comment has been minimized.

Copy link
Contributor

phemmer commented Mar 11, 2016

@phemmer Recreating the mount won't really work since the container won't see the updated mount info.

Eh? Why wouldn't it?

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Mar 11, 2016

@phemmer I mean I guess it's possible, but we'd have to enter the mount namespace, would we not?

@phemmer

This comment has been minimized.

Copy link
Contributor

phemmer commented Mar 11, 2016

@phemmer I mean I guess it's possible, but we'd have to enter the mount namespace, would we not?

Yeah, but we're docker, we can do whatever we want to our containers :-)

@crosbymichael

This comment has been minimized.

Copy link
Member

crosbymichael commented Mar 11, 2016

It would be no different than today. If you have a container with the socket bind mounted into it. Docker exits but your container keeps running, it sill cannot access the docker API. You should have your container exit and get restarted anyways if it gets an error from the socket right?

@ibuildthecloud

This comment has been minimized.

Copy link
Contributor Author

ibuildthecloud commented Mar 23, 2016

@crosbymichael That doesn't really work out well because your code talking to the socket has to special case a connect error. Typically you are using some docker client and most of the err response are opaque and treated as a typical API error. Now you have to catch and deal with this one error in a very specific way. I know on a lot of errors you might exit your application, but if I'm talking to remote API it don't just panic on the first error I see.

@ibuildthecloud

This comment has been minimized.

Copy link
Contributor Author

ibuildthecloud commented Mar 23, 2016

I do like @bboreham suggestion where I can just request the docker socket to be put in the container.

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented Oct 25, 2016

We are still looking into providing an introspection API, but no ETA for that (yet)

@MetalArend

This comment has been minimized.

Copy link

MetalArend commented Apr 23, 2017

could this not be done by adding something like the --privileged option?

@ferrx

This comment has been minimized.

Copy link

ferrx commented Feb 6, 2018

How do any of these proposed workarounds impact the CIS Docker Community Edition Benchmark control 5.31 "Ensure the Docker socket is not mounted inside any containers" https://docs.docker.com/compliance/cis/docker_ce/

Do any of these workarounds circumvent other controls? I'd imagine --privileged would not be a suitable workaround.

(Also: Does UCP bind to Docker socket? Does this mean UCP is not compliant? I'm just reading from the CIS for CE, maybe EE is different?)

@bboreham

This comment has been minimized.

Copy link
Contributor

bboreham commented Feb 6, 2018

The circumstances in which you want a container to talk to the Docker unix socket are ones in which you have already decided to grant absolute power to that container.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment