0.7.1: /sys/class/net inside a sysbox container lists the host's interfaces, not the container's

Summary

Inside a Sysbox container, /sys/class/net lists the host's network interfaces instead of the container's. ip link (netlink) is correct, so the container's network namespace itself is fine — only the sysfs view is wrong.

This breaks any program that enumerates interfaces through sysfs, and it also discloses the host's network topology to the container (bridge names, veth names, tailscale0, …).

Environment

$ uname -a
Linux femcabot 6.12.107+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.107-1 (2026-08-29) x86_64 GNU/Linux

$ sysbox-runc --version
sysbox-runc
	edition: 	Community Edition (CE)
	version: 	0.7.1
	commit: 	081856cc5d17e7095f066b08d0eca6bb0b515c47

$ docker version --format '{{.Server.Version}}'
29.8.0

containerd version: db8809540e1a7a9da5d518876894933ff55692ab

Reproduction

$ docker run --rm --runtime=sysbox-runc alpine sh -c 'ip -o link | wc -l; ls /sys/class/net | wc -l'
2
36

The 36 entries are the host's:

br-243c0eb3681f br-3d1b3d6a4815 br-4d50e06132c4 ... docker0 eth0 lo tailscale0 veth02bae1a veth0763190 ...

A plain runc container on the same host is correct:

$ docker run --rm alpine sh -c 'ls /sys/class/net'
eth0
lo

What actually happens

The network-namespace tag of a sysfs mount is fixed when the superblock is created, not evaluated per access (see the kernel's sysfs tagging documentation). Sysbox appears to hand the container a sysfs superblock that was created in the host's netns.

Consistent with that, remounting /sys inside the container changes nothing (a remount reuses the existing superblock), but mounting a fresh sysfs at a new path in the same container gives the correct view:

$ docker run --rm --runtime=sysbox-runc alpine sh -c \
    'mkdir -p /mnt/s && mount -t sysfs sysfs /mnt/s && ls /mnt/s/class/net'
eth0
lo

So the kernel is behaving correctly and the container's netns is correct; it is the superblock handed to the container that carries the wrong tag.

Impact

This is not theoretical. It broke n8n's sandbox service, whose runner verified a bridge with stat /sys/class/net/<bridge> and therefore refused to start under Sysbox: n8n-io/n8n-sandbox-service#159. They worked around it downstream by querying netlink instead (their v1.3.3), which is why this is no longer blocking for us — but any other tool that reads sysfs will hit the same wall, and the topology disclosure remains.

Possibly related, and possibly a regression: #719 reported a different malfunction in the same area in 0.6.x (broken symlinks under /sys/class/net, host devices under /sys/devices/virtual/net) and was closed as fixed after 0.6.2.

Happy to run further tests on this host if that helps.

Start by reproducing the mismatch with the provided docker run commands under sysbox-runc and compare /sys/class/net with ip link. Read the kernel sysfs-tagging documentation and trace how Sysbox provides the sysfs mount and its superblock to the container. Done means the existing /sys/class/net view shows only the container interfaces and no host topology, while a fresh sysfs mount remains correct.