--net-allow breaks GUI apps

[Dreadeath]

Hi, since 0.8.4 with --net-allow option I cannot start any GUI app. Running in Arch Linux, KDE.

[congwang-mk]

Hi @Dreadeath

This is expected, because technically Unix sockets don't belong to networking, so it is now gated by filesystem instead. So you need to add the Unix socket path used by your KDE as writable, for example -w "$XDG_RUNTIME_DIR"

[Dreadeath]

Should it work with '-w /'? It doesn't.

And in first comment I meant that if there is no any --net-allow options, I can start GUI app.

[congwang-mk]

Sorry for misunderstanding.

I just tried Unix socket with and with -w or --net-allow, I didn't see any unexpected issue. So, I guess your GUI app might be using something else like TCP loopback? Is there any way you could narrow it down?

[dzerik]

The -w / not helping is actually the key clue — it rules out pathname unix sockets (those a filesystem grant would cover) and points at two things -w can't reach on KDE:

1. TCP loopback — as you suspected. Parts of Qt/KDE (and X11 when DISPLAY is a TCP display like localhost:0) connect to 127.0.0.1. With --net-allow set you're in default-deny allowlist mode, so loopback is blocked unless it's listed.
2. Abstract unix sockets — D-Bus (which KDE leans on heavily) and often X11 (@/tmp/.X11-unix/X0) use abstract-namespace sockets: the address starts with a NUL byte (shown as @), so it has no filesystem path at all. -w / grants filesystem paths, so it can't authorize an abstract socket — which is exactly why -w / made no difference.

A quick way to pin which one it is:

strace -f -e trace=connect <gui-app>

and look at the connect() that returns EACCES/EPERM:

• sun_path="@/..." (or a leading \0) → abstract unix socket
• sin_addr=127.0.0.1 → TCP loopback
• a real path like /run/user/1000/bus → pathname unix socket

Fix per case: loopback → add 127.0.0.1 to --net-allow; pathname socket → -w <that path>; abstract socket → there's currently no grant for it (it isn't a path and isn't TCP), so today the only options are dropping --net-allow or, if applicable, turning the abstract-socket gate off.

[Dreadeath]

Ok, I tested rofi (just as an lightweight example):

strace -f -e trace=connect rofi:

[pid 142942] connect(5, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 110) = 0
strace: Process 142961 attached
[pid 142942] connect(7, {sa_family=AF_UNIX, sun_path="/run/user/1000/wayland-0"}, 27) = 0

sandlock run -w / -- rofi - all is good

sandlock run --net-allow 127.0.0.1 -w / -- rofi or sandlock run --net-allow '*' -w / -- rofi or sandlock run --net-allow :* -w / -- rofi or sandlock run --net-allow 127.0.0.1 -w / -w /run/user/1000/wayland-0 -w /run/user/1000/bus -- rofi:
(process:156191): Wayland-ERROR **: 11:49:20.055: Could not connect to wayland compositor

A few more examples
sandlock run --net-allow 127.0.0.1 -w / -- konsole:

This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

sandlock run --net-allow 127.0.0.1 -w / -- gimp:
Cannot open display:

I'm starting to think there is something in my config that causes this. I'll try running sandlock on another machine.

[dzerik]

I dug into this on kernel 7.0 against current main, and I have to correct my earlier comment — the abstract-socket angle was only half the story. There are two independent mechanisms here, and the one that actually breaks Wayland/KDE is a real bug, not a config issue.

The real bug: connected AF_UNIX sendmsg() is refused under any destination policy

The moment a --net-allow (or --net-deny) rule is set, a sendmsg() on an already-connected AF_UNIX stream socket fails with ECONNREFUSED. connect() and recvmsg() on the same socket work — only the outbound sendmsg() is rejected. libwayland and D-Bus write their protocol via sendmsg (for the fd-passing capability), so the client connects, sends get_registry, and then hangs forever waiting for a reply the compositor never got. That's the rofi / konsole symptom.

Minimal repro (any live pathname unix socket — here the Wayland display):

sandlock run -w / -- \
  python3 -c 'import socket; s=socket.socket(socket.AF_UNIX,socket.SOCK_STREAM); s.connect("/run/user/1000/wayland-0"); print("send",s.send(b"x")); print("sendmsg",s.sendmsg([b"x"]))'
# -> send 1 ; sendmsg 1        (OK)

sandlock run --net-allow 127.0.0.1 -w / -- \
  python3 -c '...same...'
# -> send 1 ; ConnectionRefusedError: [Errno 111]   <-- sendmsg only

WAYLAND_DEBUG=1 wayland-info shows it clearly: under -w / the registry streams in; add --net-allow and it stops dead right after the two outbound -> get_registry / -> sync requests.

Root cause: in sendmsg_on_behalf, the connected / non-IP-family "Continue" fast path is gated behind if !dest_policy. With a destination policy active, a connected AF_UNIX send skips that path, gets dup'd, and hits query_socket_protocol, which returns None for a unix socket (no IP protocol) — read as "unknown protocol" and refused with ECONNREFUSED. send()/sendto were never affected because they Continue connected sockets unconditionally, which is why the breakage looked so selective. sendmmsg_on_behalf has the same gap.

The IP destination policy only governs IP sockets; a --net-allow rule shouldn't change how AF_UNIX sockets are treated at all. Fix is to probe SO_DOMAIN and Continue for unix sockets before the IP path (mirroring sendto, which only takes IP-family destinations on-behalf). IP enforcement is untouched — non-unix sockets still resolve their protocol and validate every destination. Fix + integration test in #125.

The other half: X11 apps and abstract sockets (this one is by design)

Separately, X11 clients (xterm, konsole -platform xcb, gimp) fail because libxcb reaches the display over the abstract socket @/tmp/.X11-unix/X0, which LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET blocks (EPERM). That scope is on by default under any grant — it is not --net-allow-specific, and -w / can't help since an abstract socket has no filesystem path. For X11 the intended knob already exists:

sandlock run --disable abstract-unix-socket-scope -- xterm      # abstract sockets
# add --net-allow 127.0.0.1 (or --disable net-tcp) if the app also uses TCP loopback (X11 over localhost:N)

Reproduced matrix (connect() result), current main, kernel 7.0:

target	-w /	--net-allow … -w /	--disable abstract-unix-socket-scope
pathname unix (wayland-0, /tmp/.X11-unix/X0)	OK	OK (connect) — but sendmsg bug above	OK
abstract unix (@/tmp/.X11-unix/X0)	EPERM	EPERM	OK
TCP loopback	EACCES	OK (in allowlist)	EACCES

So: native Wayland (rofi) is the sendmsg bug; X11 is the abstract-socket scope. Your TCP-loopback guess was right for the X11-over-TCP case, just not the whole picture.