Hm. In #7841 you proposed to add a --plugin flag to add the socket, this PR will mount the socket for any container that has --privileged. I think either this PR or the proposal should be updated to mention this.

Wondering; is logical to assume that all privileged containers also want to have a socket?

(I agree that naming the flag --plugin will become confusing if Docker plugins are implemented, so some other name should be proposed)

Ps You missed a # before the issue number in your description, not sure if GitHub will automatically close the issue if it's missing?

The thought here is that something with --privileged can access docker anyway, and a container with just a socket mounted in is not any more secure than a --privileged container (since something with access to Docker by definition has access to the entire system).

Ok, sounds reasonable. In which case I guess an addendum / note should be added to the proposal with the design change?

Docs LGTM - minor comments. Ping @SvenDowideit @fredlf

I don't know... what if I want privileged but don't care about the docker socket...

@jfrazelle Ignore it?
Most people who use --privileged don't need half the power that it gives, but they have it because that's the purpose of --privileged.

ya thats true seems reasonable enough to me

On Thu, Nov 13, 2014 at 12:32 PM, Brian Goff notifications@github.com
wrote:

@jfrazelle https://github.com/jfrazelle Ignore it?
Most people who use --privileged don't need half the power that it gives,
but they have it because that's the purpose of --privileged.

—
Reply to this email directly or view it on GitHub
#9135 (comment).

Alternatively, we could add a new flag, --http-socket or something.

+1 !!

please explain to me why we would not also mount the Docker binary into this container too?

and what happens if there is a conflict - ie, does this cause dind weirdness? or worse, if i intentionally added a file by that name into my image.

(I really want this, but i want it fully - the current server's Docker binary too)

@SvenDowideit I'm not sure how to mount in the binary... I think it's already happening at /.dockerinit, though.

If you added a file by that name to the image, it would be mounted over.
If you started a new daemon trying to use that same socket location, you'll get a "device or resource busy"
So maybe we can change the socket path to /.docker.sock or something to mitigate that.

And doing a -v /var/run/docker.sock:/var/run/docker.sock mounts over it as well, so should be no problem there.

I would just install the Docker binary if you really needed it. But you don't always need it since you can use the socket from any Docker client library.

@progrium that argument can be made about the socket too - imo, if we're going to add the socket as a convenience, then giving the container a working client would make it futureproof - whereas relying on an installed client library means that you need different versions of the image whenever the daemon API version changes.

Mounting the Docker binary won't work in many, many cases, including and
especially almost all our distro-provided packages.

not to mention its a bit weird... we don't mount any other binaries..

As an image author, I can include the binary in the image if I need it. I cannot include the socket. The user has to mount it. That is the main point of the problem we're trying to solve. I honestly don't care if the binary is included or not. I will probably not use it.

perfectttt

ok, sold - though your client may be out of date, you're right at least you can.

Docs LGTM when its updated to match the comments.

Rebased. Docs updated.

Docs LGTM

Docs LGTM - @fredlf

I don't think this is an expected behavior for --privileged. Something like this ought to stay an explicit action by the caller of docker run with -v /var/run/docker.sock:/var/run/docker.sock

If plugins are needing a communication back to the daemon, perhaps define a new means like a /dev/docker-plugin-control or such, rather than overloading a behavior that could interfere with existing expectations.

Heh, this will probably also cause problems with our integration tests,
which are run inside a privileged container that expects to be able to
setup dind on /var/run/docker.sock inside the container (which we can
change, but that's another hoop to jump through for this change, and we
won't be the only ones).

For sure we can put the socket elsewhere easily enough.
I think this is not overloading so much as giving more privilege (or rather easier access to privilege), and makes the life of people making containers that depend on talking to docker (ie, event watchers, ambassadors, etc).

Keep in mind, not all daemon's have a unix sock available to mount in.

the cmd() function has been removed from the test utils so the tests will need to be updated

Updated, also changed location of socket to /.docker.sock

Are we sure we should automagically be doing this? I'm still hesitant

I do not like this at all and it's much better to be explicit. It's not that hard at all if you have to specify --privileged to specify -v /var/run/docker.sock:/var/run/docker.sock

Lets not do this as the cons of adding this vastly outweigh the pain of adding a flag especially when you don't want extra linux CAPs, security profiles.

NOT LGTM

I agree, NOT LGTM