Open colinmarc opened 1 week ago
More debugging. If I run both hack
and udevadm monitor
via sudo nsenter -t $PID -n ...
, then the events are propagated. Neither running udevadm monitor
via the container shell and hack
via nsenter
or the inverse, seem to work.
If I run both
hack
andudevadm monitor
viasudo nsenter -t $PID -n ...
, then the events are propagated.
Does $PID there represent the network namespace associated to a Podman container, or it's the one from ip netns add
?
To me it looks like the difference is whether you detach the network namespace as root, or together with a user namespace as non-root. In the second case, I guess, the kernel will not accept your crafted netlink message.
Does $PID there represent the network namespace associated to a Podman container, or it's the one from ip netns add?
Yes, the podman container namespace, fetched via podman inspect --latest --format "{{.State.Pid}}"
.
I get the same result running completely rootless with nsenter -t $PID -U -n ...
(no sudo
). If I run both the listener and the broadcaster that way, it works fine. Running either end inside the container shell doesn't. That's despite supposedly having the right caps in the container shell:
root@c8564d96e73b:/# grep Cap /proc/$BASHPID/status
CapInh: 0000000000000000
CapPrm: 000001ffffffffff
CapEff: 000001ffffffffff
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
Edit: also, just to add, running this without caps (no --privileged
or without sudo on the host) results in a clear EPERM
from the kernel. This is just failing silently.
Issue Description
I'm working on a
hacksophisticated bit of software that broadcastsudev
events via aAF_NETLINK, SOCK_RAW
socket. I've attached some very rough/hacky rust code at the bottom which should be easy enough to compile and run.The test program works fine on the host machine (as root), as well as in a normal netns, for example with the following steps:
(and then in another shell)
However, it doesn't seem to work in rootless Podman network namespaces. I tried both
--net=pasta
and--net=slirp4netns
.For background,
uevents
are used to provide hotplug information to running processes. For example, if you plug in a keyboard, it will generate a bunch of them. As of recent-ish kernels, those events are "namespaced" in the sense that they are only broadcast to listening sockets in the same network namespace.Steps to reproduce the issue
Start a podman container:
In the container, install a few tools and then run udevadm monitor:
And in another shell, run the test:
Describe the results you received
udevadm didn't pick up any events.
Describe the results you expected
On the host, or in a normal network namespace, this produces the following:
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
No response
Additional information
Here's the rust code: