Re: [PATCH] RFC: Don't override system's default ping_group_range for pasta

On Tue, 8 Sep 2026 16:24:04 +1000 David Gibson wrote:

On Sun, Sep 06, 2026 at 12:05:27PM +0200, Stefano Brivio wrote:

...

On Thu, 20 Aug 2026 17:17:48 +1000 David Gibson wrote:

...

When spawning a command, pasta sets the net.ipv4.ping_group_range sysctl to 0 0, meaning only group 0 can use ping sockets within the namespace. Since group 0 is the only one we map in the userns, that's equivalent to anyone being able to use ping sockets.

Although the kernel default for this is 1 0 (nobody can use ping sockets), common distros - at least ones using systemd or even just systemd-udevd - appear to set it to "0 2147483647" meaning effectively anyone can use ping sockets.

This wasn't the case on CirrOS (https://github.com/cirros-dev/cirros) and on some more common distributions. For example Alpine sets it to "999 59999", so group 0 is excluded.

Ah, hm, right.

...

I haven't checked other distributions not running systemd, but I would expect similar outcomes.

...

There's no obvious reason that we need to override the system's default behaviour here. The override was introduced in 32d07f5e5 ("passt, pasta: Completely avoid dynamic memory allocation") as part of a large chunk which kind of looks like it was meant to be in another patch, so the git history isn't particularly informative.

Kind of: the override was actually introduced by 089dec90ca99 ("pasta: Set ping_group_range upon namespace creation"), which I dropped by mistake (pasta.c not committed) in 675174d4ba25 ("conf, tap: Split netlink and pasta functions, allow interface configuration"), and finally added back by committing pasta.c in 32d07f5e59f2 ("passt, pasta: Completely avoid dynamic memory allocation").

It's not really informative anyway. But, in any case, unless this does any harm, I'd rather keep the override, because ping might otherwise break on a number of distributions.

Doesn't really do any harm - that's why this is RFC. I had plans to move lots of the stuff in this function to various other places in order to facilitate dealing with the close_range() versus spawned process problem.

But yeah, if a bunch of distros don't allow ping from group 0, that will break things.

Although... currently we map UID 0 in the namespace to the calling user in the parent (like unshare -Ur). In some ways it would make more sense to identity map the parent UID (like unshare -Uc), but let the spawned process retain CAP_NET_ADMIN so it can still configure the network. We're operating basically in the parent filesystem, in which context we "feel" close to being the parent user than root, even though we have root-like privilege to control the pasta network.

If we did so, that would fix the ping issue as a side effect - if we're in the ping group range as the parent UID (which pasta would need to forward pings anyway) then we should also be so in the namespace.

...maybe, yeah. It doesn't really feel like a priority to me though. -- Stefano