[Bug]: publish-socket cannot relay a socket on tmpfs with read-only root

[JustFrank122]

Summary

--publish-socket accepts a host connection but does not relay it to a Unix socket created under /dev/shm in a --read-only container. The host receives EOF. The same socket server works from inside the container, and a writable-root /tmp control relays successfully.

This makes it impossible to combine a read-only root filesystem with a container-to-host Unix control socket whose mutable state lives on tmpfs.

Minimal reproduction

Start the service:

container system start

container run --detach --name uds-tmpfs-test \
  --platform linux/arm64 \
  --network none --no-dns \
  --read-only --shm-size 64M \
  --publish-socket /tmp/uds-tmpfs-test.sock:/dev/shm/relay.sock \
  --entrypoint /usr/local/bin/python3.11 \
  python:3.11-slim-bookworm \
  -c 'import os,socket; p="/dev/shm/relay.sock"; s=socket.socket(socket.AF_UNIX); s.bind(p); os.chmod(p, 0o777); s.listen(); c,_=s.accept(); c.sendall(c.recv(4))'

From the host, after /tmp/uds-tmpfs-test.sock exists:

python3 - <<'PY'
import socket
s = socket.socket(socket.AF_UNIX)
s.connect("/tmp/uds-tmpfs-test.sock")
s.sendall(b"PING")
print(repr(s.recv(4)))
PY

Expected: b'PING'.

Actual: b''.

The server socket is deliberately root-owned and mode 0777; /dev/shm is root-owned and mode 1777. A direct client run inside the same container receives b'PING' from /dev/shm/relay.sock.

Control

The same server and host client work when the root filesystem is writable and the relay target is /tmp/relay.sock:

# Omit --read-only and replace both /dev/shm/relay.sock occurrences with /tmp/relay.sock.

The host client then prints b'PING'.

A second strict control with --read-only --tmpfs /run and target /run/relay.sock also returns b'' from the host.

Why this appears to be a relay/path-visibility problem

The CLI configures a published socket as an outOf Unix socket relay (source). The pinned Containerization dependency resolves that source beneath the container rootfs before asking vminitd to relay it (source); the guest proxy subsequently opens a Unix socket at that path (source).

The observed behavior is consistent with the relay not seeing a socket on the process namespace tmpfs. I cannot directly inspect vminitd's mount namespace through the supported CLI, so this is an inference rather than a claim of root cause.

Is publishing a socket from /dev/shm or an explicit container tmpfs expected to work? If not, is there a supported way to expose one container-owned Unix socket while keeping the root filesystem read-only?

Environment

• macOS 26.5.2 (25F84)
• Container CLI 1.1.0 (5973b9c)
• Apple silicon / linux/arm64
• Xcode unavailable; Command Line Tools selected

I searched existing issues for published-socket/tmpfs/read-only reports and did not find a match. I agree to follow the Code of Conduct.

[JustFrank122]

Follow-up: I ran the missing writable-root controls with the same minimal echo server.

• Writable root + /dev/shm/relay.sock: host receives b.
• Writable root + --tmpfs /run + /run/relay.sock: host receives b.
• Writable root + rootfs /tmp/relay.sock: host receives b'PING'.

So --read-only is not causal; the observed boundary is any tmpfs-mounted target path versus a writable rootfs target. The socket is root-owned and mode 0777 in each case.

[JustFrank122]

One last verification for those writable-root tmpfs controls: after the host relay returned b, a direct Unix client executed inside each same container successfully exchanged PING with the /dev/shm and /run servers. This rules out server bind/listen failure in the controls as well.