Support for sharing unix sockets

[BouncyLlama]

Expected behavior

When mounting a directory containing unix sockets the sockets should function the same as they do on a Linux host.

Actual behavior

The socket is 'there', but non-functional.

Information

After reading several forum threads, it appears that there is a workaround with socat over TCP, but this is rather slow.

The documentation has this to say: 'Socket files and named pipes only transmit between containers and between OS X processes -- no transmission across the hypervisor is supported, yet' Hopefully this is a planned feature already, but I did not see any existing issues open in this tracker for this particular issue, although it relates to #410 which asks specifically for SSH_AUTH_SOCK to be supported.

Host OS: Mac OSX 10.10.5

Steps to reproduce the behavior

1. mount a directory containing unix sockets like so: '-v "/directorywithsockets:/otherdirectory"'
2. attempt to send data to/from the host/container via the socket

[dsheets]

This is on the roadmap.

[udondan]

Interestingly, even a socket created in the container is non-functional if it was created on a mounted volume of the host.

[jippi]

Any ETA on this? :)

Currently it's blocking https://github.com/hashicorp/nomad/issues/1091 and other projects :)

[dsheets]

This is currently scheduled for resolution in November. Sorry for the delay.

[jippi]

@dsheets okay, will it be available in beta builds beforehand?

[dsheets]

Our goal is to ship it in beta builds in November.

[jippi]

amazing @dsheets - if you need any testing or otherwise beforehand, I'm willing to help out!

[Druotic]

Our goal is to ship it in beta builds in November.

@dsheets That statement makes me think the work for this is already underway. However, the status label is still "1-acknowledged". Is this currently being worked on, or still on the todo list?

[BlinkyStitt]

We are in November now :) Any guess when this will be in Beta? This feature blocks a lot for us.

[Druotic]

Any updates? Even a mention that this feature has been abandoned would be better than nothing.

[dsheets]

The feature has not been abandoned. It is still on the roadmap. Thanks for your patience.

[BlinkyStitt]

It is the last day of November. Any update on when this will be in the beta @dsheets?

[dsheets]

Work has begun but is currently delayed behind performance work. Sorry about that. Stay subscribed to get updates. Thanks for your patience!

[gugahoi]

Any updates on this?

[BlinkyStitt]

I've started using https://github.com/avsm/docker-ssh-agent-forward to work around this issue

[BlinkyStitt]

Any updates @dsheets ? Is there an issue tracking the performance work? If that is going to block for much longer, I am planning to spend some time cleaning up https://github.com/avsm/docker-ssh-agent-forward but if docker will have proper support soon I won't bother.

[KFoxder]

+1

[dsheets]

Support for this is planned and has been started but is delayed indefinitely behind other work. @WyseNynja I would recommend cleaning up avsm/docker-ssh-agent-forward in the meantime.

[johnmccabe]

The docker-ssh-agent-forward workaround is working well for me, I've raised avsm/docker-ssh-agent-forward#9 with some fixes.

Keeping fingers crossed for this fix tho.

[BlinkyStitt]

I've merged a bunch of changes from avsm's helpful fix into a new fork that is on docker hub: https://github.com/uber-common/docker-ssh-agent-forward

[twexler]

It's nearly the end of March... any update on this work? I actually need to use this for something that isn't SSH.

[dsheets]

@twexler we are looking at the Q2 roadmap now and this support is contending with other work (mostly performance related) for priority. If you (or anyone else receiving this) have use cases that aren't X11 or SSH (these are great but more use cases are always better), we'd really, really love to hear about them to help make the case to prioritize this work. Thanks!

[jancurn]

Here's one use case. We're considering using UNIX sockets so that a process running in the Docker container can notify another process running in the host system that it is already listening on some specific TCP port, without a need for periodic polling of that port. This works great on Linux, but not in our development environment on macOS. From my perspective, feature parity between the development and production environment is more important than performance.

[gugahoi]

It's incredibly frustrating to be able to share the socket in linux boxes but not on my dev machine. Feature parity is definitely more important than performance for me as well, after all this is one of the greatest use cases for docker: run the same thing no matter the underlying OS.

[twexler]

My use case is reaching Postgres(or MySQL, doesn't matter) via a socket. Doesn't make sense to have it listen on 0.0.0.0 just so containers can access it.

[dsheets]

Thank you, I have updated our tracking issue with the mixed host-container use case and dev/prod parity requirement. I've also added the database socket use case. I think these should be compelling enough to (finally) get this shipped. Thank you for your patience and sorry it has taken this long. 🙂

[pkschweiger]

Hope you managed to realize a good chunk of the performance improvements you prioritized. Stoked you're getting around to this.

Thank you for your patience and remaining polite throughout a year of our nagging :trophy:

[JockDaRock]

Use Case: Forwarding Mac host network packets to a container for analysis and intrusion Detection.

Issues: using named pipes (e.g. something.fifo) to share data for my container is a workaround for me. For my project, I would really need to be able to share host network interfaces with the container on Docker for Mac, like in the Linux version of Docker. This is to be used for reading network packets for an IDS. Since this is not achievable currently, and it doesn't seem that Docker will support sharing host interfaces anytime soon, I decided to try using named pipes to dump network packets in through TCPDump. this obviously did not work and why I am here now to share my use case.

Current Objective: Since it seems I have a better chance of Docker supporting named pipes, I am arranging the usage of my project for Mac around the apparent use of named pipes to share network packets with my container instance.

That being said, I would much prefer to use --net=host 😄

[Mange]

I got this to work using socat as a workaround for now. I start a socket-to-tcp proxy on the host, expose the port to the container, and then start a tcp-to-socket proxy inside the container.

Wrapper script on host:

image_name=...

socat TCP-LISTEN:3434,reuseaddr,fork "UNIX-CLIENT:$SSH_AUTH_SOCK" &
socat_pid=$!
trap "kill -- $socat_pid" EXIT

docker run \
  --interactive --tty --rm \
  --network=host \
  -p 3434 \
  $image_name \
  bin/container-ssh-wrapper "$@"

Then in the container wrapper script:

# Create UNIX socket to port 3434 to the host, where the SSH agent is proxied.
export SSH_AUTH_SOCK="$HOME/ssh-agent.socket"
socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork TCP:localhost:3434 &

exec "$@"

This seems to work well. It will not support running multiple instances at the same time because of the fixed port number, but that should be very easy to fix if you have that requirement. You can determine a free port number on the host and pass it as an environment variable to the container.

Both Ubuntu and Homebrew on Mac OS X have socat in their repositories. My wrapper script automatically installs them on the host if not already installed, so user setup is very low.

Looking forward to having this native, but this might help some people deal with it until then. :smile:

[shenberg]

We use FIFOs for high-speed message-passing between two dockers. Performance-wise, on a linux box it demolished using stdin/stdout with --log-driver=none, and was around 30% faster than unix domain sockets.

[JockDaRock]

Agreed @shenberg! FIFOs are preferable over UNIX socks!

[trinitronx]

FIFOs do not solve the same problems as unix sockets:

UNIX domain sockets and FIFO may share some part of their implementation but they are conceptually very different. FIFO functions at a very low level. One process writes bytes into the pipe and another one reads from it. A UNIX domain socket has the same behaviour than a TCP/IP socket.

A socket is bidirectional and can be used by a lot of processes simultaneously. A process can accept many connections on the same socket and attend several clients simultaneously. The kernel delivers a new file descriptor each time connect(2) or accept(2) is called on the socket. The packets will always go to the right process. On a FIFO, this would be impossible. For bidirectional communication, you need two FIFOs, and you need a pair of FIFOs for each of your clients. There is no way of writing or reading in a selective way, because they are a much more primitive way to communicate.

Interfacing with existing processes such as ssh-agent which use unix sockets can't easily be solved by simply using FIFOs instead. Therefore, the need surfaced by this issue is still valid.

[automaticgiant]

openssh can forward unix sockets. would this help as part of a workaround?

[koyabr]

Any update on this?

[hilt86]

+1

[trinitronx]

@automaticgiant : There was a workaround using this method posted in #410 in this comment. The need for full unix socket support is still valid, as this workaround is just that: a workaround.

[dahu33]

Any update? This really blocking the full potential of docker for mac...

[yuriipolishchuk]

+1 for sharing unix sockets

[ksylvan]

+1

[DestyNova]

Is there a workaround for this that works in the build step? The methods involving socat only work with docker run to use the --net and -p features, meaning it won't work during docker build.

[jeeftor]

Any updates?

[gideonred]

Moment for a fun fact: this is stopping Docker DOOM from working on a macOS host.

[JockDaRock]

Ok @Docker, no DOOM is sad, amongst other things that we could be doing with this fix... Time to fix this issue on MacOS!

What say you?

[KernelFolla]

+1 for a common way to share the ssh agent This is my desperate approach after I spent half day trying everything, maybe it can help someone https://gist.github.com/KernelFolla/a6b5150ca6187cc3222923ce53f19084 I bypass the entry point to start a new ssh agent.

[twexler]

@dsheets It's almost the end of august now...what's up with this work? do you guys need some help?

[marcelocarlos]

@dsheets I'm not a big fan of "ping" messages (like the one I'm writing now), but since the last update was in March, can you provide us with any update on this issue?

[domdom82]

this issue is a roadblock for us as we try to provide a common image for all developers on shared VMs. we never want a SSH key to appear anywhere so we use ssh agents to host the keys in memory and never store them on disk. this makes it impossible work around the problem by mounting private keys in a container and then starting another ssh-agent in the container.

@Mange 's workaround with socat seems viable for the time being - but I really don't want my code to be riddled with if uname == Darwin clauses.. so 👍 on a final solution!

[alexgottscha]

Is there an actual ETA for this? It's a year after beta fixes were promised, and this will have some impact on whether I bother to get a Mac for my next system.

[quinn]

This is currently inhibiting my ability to test something that depends on a mysql socket locally. This would great to have this feature fixed on os x....

[domdom82]

In case you don't want to / can't use socat... Following up on @Mange 's workaround here is a solution without using socat, only pure netcat:

On the host:

mkfifo myfifo
nc -lk 12345 <myfifo | nc -U $SSH_AUTH_SOCK >myfifo

On the container:

mkfifo myfifo
while true; do
  nc docker.for.mac.localhost 12345 <myfifo | nc -Ul /tmp/ssh-agent.sock >myfifo
done &

export SSH_AUTH_SOCK=/tmp/ssh-agent.sock

ssh ...

This bypasses the socket connection over tcp. Since it is netcat only you have to re-establish the connection manually after the pipe has disconnected.