Replies: 5 comments 1 reply
-
More debugging. If I run both |
Beta Was this translation helpful? Give feedback.
-
Does $PID there represent the network namespace associated to a Podman container, or it's the one from 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. |
Beta Was this translation helpful? Give feedback.
-
Yes, the podman container namespace, fetched via I get the same result running completely rootless with
Edit: also, just to add, running this without caps (no |
Beta Was this translation helpful? Give feedback.
-
A friendly reminder that this issue had no activity for 30 days. |
Beta Was this translation helpful? Give feedback.
-
Did you try running podman as root (i.e. with sudo). To me this simply sounds like the kernel broadcast for rootless (user namespaces) I would assume. I doubt that can do anything here so I move this to a discussion |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
Beta Was this translation helpful? Give feedback.
All reactions