Summary
In WSL Containers (WSLC) public preview, a process inside a container cannot create an AF_VSOCK socket — socket(AF_VSOCK, SOCK_STREAM, 0) fails with EPERM. This blocks host↔container communication over Hyper-V sockets. There is no wslc run/create flag (--privileged, --security-opt, --cap-add, --device) nor any settings.yaml option to relax the seccomp/security policy, so there is currently no supported workaround.
Repro
# Dockerfile
FROM ubuntu:22.04
COPY vsock_server /vsock_server # any program that calls socket(AF_VSOCK, SOCK_STREAM, 0) + bind/listen
ENTRYPOINT ["/vsock_server"]
wslc build -t vsock-test .
wslc run --name v vsock-test
# -> socket error: Operation not permitted (EPERM on socket(AF_VSOCK))
Actual vs. expected
- Actual:
socket(AF_VSOCK, …) returns EPERM; the container cannot open a vsock socket at all.
- Expected: a supported way to permit
AF_VSOCK (e.g. --security-opt seccomp=unconfined, a configurable seccomp profile, or --privileged), consistent with Docker.
This is a policy block, not an architecture limit
- The container runs on the shared WSL2 kernel (
wslc run --rm ubuntu:22.04 uname -r → 6.18.40.1-microsoft-standard-WSL2), which fully supports AF_VSOCK (it works fine from a normal WSL distro on the same kernel).
- The failure is
EPERM, not EAFNOSUPPORT → the family is supported but denied by policy (seccomp/LSM), i.e. the default container profile filters AF_VSOCK.
What's missing
wslc run, wslc create, wslc system, and settings.yaml expose no security/seccomp/capability/privileged/device controls, so there is no way to allowlist AF_VSOCK.
Request
Add a Docker-compatible escape hatch — one or more of:
--security-opt seccomp=<profile|unconfined>--privileged- allowlist
AF_VSOCK in the default seccomp profile (or a documented opt-in)
so containers can use Hyper-V sockets for host↔guest IPC.
Related
Environment
- WSL 2.9.9.0 (pre-release), kernel 6.18.40.1-microsoft-standard-WSL2
- Windows 10.0.26220.9223
wslc 2.9.9.0
Summary
In WSL Containers (WSLC) public preview, a process inside a container cannot create an
AF_VSOCKsocket —socket(AF_VSOCK, SOCK_STREAM, 0)fails withEPERM. This blocks host↔container communication over Hyper-V sockets. There is nowslc run/createflag (--privileged,--security-opt,--cap-add,--device) nor anysettings.yamloption to relax the seccomp/security policy, so there is currently no supported workaround.Repro
Actual vs. expected
socket(AF_VSOCK, …)returnsEPERM; the container cannot open a vsock socket at all.AF_VSOCK(e.g.--security-opt seccomp=unconfined, a configurable seccomp profile, or--privileged), consistent with Docker.This is a policy block, not an architecture limit
wslc run --rm ubuntu:22.04 uname -r→6.18.40.1-microsoft-standard-WSL2), which fully supportsAF_VSOCK(it works fine from a normal WSL distro on the same kernel).EPERM, notEAFNOSUPPORT→ the family is supported but denied by policy (seccomp/LSM), i.e. the default container profile filtersAF_VSOCK.What's missing
wslc run,wslc create,wslc system, andsettings.yamlexpose no security/seccomp/capability/privileged/device controls, so there is no way to allowlistAF_VSOCK.Request
Add a Docker-compatible escape hatch — one or more of:
--security-opt seccomp=<profile|unconfined>--privilegedAF_VSOCKin the default seccomp profile (or a documented opt-in)so containers can use Hyper-V sockets for host↔guest IPC.
Related
Environment
wslc2.9.9.0