Socket/pipes in mounted volumes not working?

Docker Desktop
1

Expected behaviour

I was trying to use the ideas here: Running GUI apps with Docker | fabiorehm.com to expose XQuartz socket under /tmp to the container, and found it couldn’t open the display although I could see the socket in the mounted directory and all security on XQuartz was disabled.

As a smoke test I used mkfifo to create a pipe in the mounted tmp directory. I ran tail -f on the pipe on my Mac and used cat in the container shell to fire strings at it, which works from another terminal on my Mac. I assume that this has worked in the past because the thread at the link above seems to show the approach working for several people.

Actual behaviour

Nothing came through the pipe. There was no error on the container side.

Information

OS X: version 10.10.5 (build: 14F1713)
Docker.app: version v1.11.1-beta12
Running diagnostic tests:
[OK] Moby booted
[OK] driver.amd64-linux
[OK] vmnetd
[OK] osxfs
[OK] db
[OK] slirp
[OK] menubar
[OK] environment
[OK] Docker
[OK] VT-x
Docker logs are being collected into /tmp/20160520-155915.tar.gz
Most specific failure is: No error was detected
Your unique id is: 14AB7F8C-1B49-4A5D-A73D-10E8130B673B
Please quote this in all correspondence.

Steps to reproduce the behavior

(Not simplified, closest to what I did)

  1. Dockerfile
FROM ubuntu:14.04

RUN apt-get update && apt-get install -y firefox

# Replace 1000 with your user / group id
RUN export uid=504 gid=20 && \
    mkdir -p /home/developer && \
    echo "developer:x:${uid}:${gid}:Developer,,,:/home/developer:/bin/bash" >> /etc/passwd && \
    echo "developer:x:${uid}:" >> /etc/group && \
    echo "developer ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/developer && \
    chmod 0440 /etc/sudoers.d/developer && \
    chown ${uid}:${gid} -R /home/developer

USER developer
ENV HOME /home/developer
#CMD /usr/bin/firefox
CMD /bin/bash
  1. Run

docker run -ti -v /tmp:/tmp -e DISPLAY=/tmp/com.apple.launchd.cXKXvRE9yp/org.macosforge.xquartz:0 firefox

  1. In Mac /tmp

mkfifo testpipe
tail -f testpipe

  1. in container /tmp

    cat > testpipe
    stuff I type here does not show up on Mac

2

Trans-hypervisor named sockets and pipes are not yet supported as discussed in the documentation. Support for transmission through UNIX domain socket files and pipe files is planned but we don’t have a definite time frame for that feature.

In the meantime, I suggest using tools like socat to plumb together your use case. I recommend using different pipe files on the host and guest for now. Then, when we do support trans-hypervisor pipes, you can simply remove socat and align the pipe files on both sides of the connection.

Thanks for participating in the Docker for Mac Beta!

David

3

Thanks David, I’ll look into that.

Cheers,
Robin

4

Has any progress been made on named sockets and piped from the Docker front?

5

Support is planned for Q2 and tracked by https://github.com/docker/for-mac/issues/483. Please subscribe there for updates. If you have a use case that is not mentioned in that issue, posting a description of your use case would be very helpful.

Thanks!

6

@dsheets Thank you for your fast response.

Use Case:
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 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.

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 that.

That being said, I would much prefer to use --net=host or have a feature that is similar to a transparent network like in Docker for Windows (although I am not completely sure about that for Windows. Haven’t tested it yet.)

If you have any further thoughts that would be much appreciated.

Kind Regards.

7

--net=host is tracked by https://github.com/docker/for-mac/issues/68. Your use case is interesting and I think in most cases shared sockets/fifos will be easier to support than shared network interfaces. If you wouldn’t mind, posting your use case to docker/for-mac#483 would be helpful. Just so you are aware, shared UNIX domain sockets will likely arrive before shared FIFOs as they have more use cases.

8

Yeah, I have read thru that issue :smile:. That being said, I haven’t really tried to support unix socks as part of my packet ingestion, as it is dependent on some other libraries I am not currently in control of or developing on. But one of my colleagues seems think it should.

I will post my use case on issue 483 as you have asked.

Docker Linux currently supports shared unix socks and shared pipes, right?

9

Yes, Docker on Linux supports shared unix sockets and pipes as the VFS is shared between host and container.