[SOLVED] When mounting /var/run/docker.sock into a container, which file system is used for volume mounting?

Issue

I have a container that contains logic for coordinating the deployment of the microservices on the host - let's call this service the deployer. To achieve that, I have mounted the /var/run/docker.sock file from the host into that deployer container.

So, when performing docker run hello-world from within the deployer container, the host runs it. This system works as expected, except for one thing I have become unsure about now, since I have seen some unexpected behaviour.

When performing docker run -v "/path/to/src:/path/to/dest" hello-world, what folder will Docker be looking at? I'm seeing two valid reasonings:

• A) It will mount /path/to/src from within the deployer to the hello-world container, since that is the shell that performs the command.
• B) It will mount /path/to/src from the source to the hello-world container, since the docker.sock determines the context and the command is being ran on the host.

Which of those is correct?
Moreover, when using relative paths (e.g. in docker-compose), what will be the path that is being used?

Solution

It will always use the host filesystem. There isn’t a way to directly mount one container’s filesystem into another.

For example:

host$ sudo docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock docker sh
0123456789ab# docker run -v /:/host --rm -it busybox sh
13579bdf0246# cat /host/etc/shadow

The last command will print out the host’s encrypted password file, not anything in the intermediate container.

If it isn’t obvious from the example, mounting the Docker socket to programmatically run Docker commands has massive security implications, and you should carefully consider whether it’s actually a good approach for you.

I’m pretty sure relative paths in docker-compose.yml won’t actually work with this setup (because you can’t bind-mount things out of the intermediate container). You’d have to mount the same content into both containers for one to be able to send files to the other. Using named volumes can be helpful here (because the volume names aren’t actually dependent on host paths); depending on what exactly you’re doing, a roundabout path of docker create and then docker cp could work.

At an implementation level there is only one Docker daemon and it runs on the host. You can publish its socket to various places, but ultimately that daemon receives requests like “create a container that mounts host directory /x/y” and the daemon interprets those requests in the context of the host. It doesn’t know that a request came from a different container (or, potentially, a different host; but see above about security concerns).

Answered By - David Maze