systemd-tmpfiles does not pick up socket liveliness if process runs in different network namespace

[martinetd]

systemd version the issue has been seen with

259.6

Used distribution

Fedora 44

Linux kernel version used

6.19.14-300.fc44.x86_64

CPU architectures issue was seen on

x86_64

Component

systemd-tmpfiles

Expected behaviour you didn't see

systemd-tmpfiles regularily removes my X11 unix socket /tmp/.X11-unix/X0 because I run xwayland-satellite in a restricted bwrap environment in a different network namespace.

Running with debug logs, I'd expect to see

Jun 27 19:43:01 xxx systemd-tmpfiles[174148]: Skipping "/tmp/.X11-unix/X0": live socket.

Unexpected behaviour you saw

But instead only get timestamp considered:

Jun 27 19:43:12 xxx systemd-tmpfiles[174312]: File "/tmp/.X11-unix/X0": modify time Sat 2026-06-27 19:43:08.154012 JST is too new.

Steps to reproduce the problem

It's easy to reproduce running a dummy program listening there in bwrap, e.g.

bwrap --unshare-net --dev-bind / / socat unix-listen:/tmp/.X11-unix/X2 stdio:

without --unshare-net the socket is listed in /proc/net/unix, but as it is above it's not.

Additional program output to the terminal or log subsystem illustrating the issue

Inspecting with strace I understand that it's because systemd-tmpfiles checks for liveliness through /proc/net/unix, but running in a separate network namespace means the socket is not listed there: is there any other way to check efficiently? (e.g. lsof does pick it up but it's not exactly great to parse all open files..)

[bluca]

You can mask the tmpfiles.d config to stop this from happening with:

touch /etc/tmpfiles.d/x11.conf

[martinetd]

Yes, or for my personal case I can have the jail touch the socket everyday or something (so if it's not running the socket is deleted properly after a while); but it's still an unexpected behaviour in my opinon.

I do agree that connecting to random sockets isn't a solution I'd accept either, it could also cause weird behaviours with programs that don't handle being connected to well, and there are also datagram unix sockets...
In the current state of linux I'd say listing all network namespaces and parsing /proc/net/unix from all namespaces at systemd-tmpfiles startup is probably the cleanest way forward, but I think that's something worth discussing with kernel folks if we don't find anything better.

[lionheartyu]

Yes, or for my personal case I can have the jail touch the socket everyday or something (so if it's not running the socket is deleted properly after a while); but it's still an unexpected behaviour in my opinon.

I do agree that connecting to random sockets isn't a solution I'd accept either, it could also cause weird behaviours with programs that don't handle being connected to well, and there are also datagram unix sockets... In the current state of linux I'd say listing all network namespaces and parsing /proc/net/unix from all namespaces at systemd-tmpfiles startup is probably the cleanest way forward, but I think that's something worth discussing with kernel folks if we don't find anything better.

A cleaner implementation method will, however, sacrifice performance.
hmmm,If performance has to be sacrificed, it might be better to regulate the users' behavior instead.

[martinetd]

I'm sure we don't want anything very slow like lsof (parsing all /proc/*/fd/*), but normal users don't have hundreds of network namespaces around so if we can enumerate them once at tmpfiles startup I don't think it'd be slow as to be prohibitive here?

Unfortunately I had a quick look and while there's a convention to record named network namespaces in /run/netns or /run/user/*/netns/, anonymous ones as created by bwrap --unshare-net aren't listed, so one would need to check /proc/*/ns/net and I think it's a bit borderline (mostly because I find it ugly, it only takes ~5ms to spawn readlink /proc/*/ns/net on my system)
If we can get there then going through the handful of network namespaces to check /proc/net/unix likely isn't too bad.

Well, as said above I don't think there's any hurry, but I think it's something that wasn't really considered and if nobody knows of a clean interface for this then it's worth bringing to kernel lists; I can do that in a couple of weeks if nobody chips in by then.

[lionheartyu]

Yes, we need to achieve it in an elegant manner.

[poettering]

it seems backwards to me to install namespaced socket inodes in a dir owned by the host. maybe do it the other way round: bind socket outside, pass the bound socket in. But for security reasons it's really weird to do the reverse

[martinetd]

I don't see why a sandbox wouldn't be able to bind something on the host? This is exactly like docker --publish option: you run a restricted process, but you still need to interact with it somehow.

In my particular case, xwayland-satellite doesn't need anything but a wayland socket, and provides a X11 socket, and interacts with programs I don't trust (e.g. binary games), it's the perfect example of program that's worth isolating.
Of course I also isolate the untrusted X11 client, so I'm binding the (now host) X11 socket to the client sandbox as well, and I don't strictly need the X11 socket to live in /tmp/.X11-unix... But why use another path? I can also use this X11 server with trusted clients (if no other client is alive), it's not worth the trouble to use another path to me.

EDIT: well, the obvious solution is to spawn a dedicated xwayland-satellite whenever I run such an app, so if nothing comes out of this issue I'll probably do that, but waiting for the server to be ready etc is a bit of a hassle so I'd rather keep my current approach if viable.
I also think there could be other such use cases, it's just that most programs are sane enough to not keep their socket in a world-writable tmp directory...