On Sun, Sep 06, 2026 at 12:05:27PM +0200, Stefano Brivio wrote:
> On Thu, 20 Aug 2026 17:17:48 +1000
> David Gibson <david@gibson.dropbear.id.au> 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.

> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  pasta.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/pasta.c b/pasta.c
> > index 5aa56b78..4248b508 100644
> > --- a/pasta.c
> > +++ b/pasta.c
> > @@ -198,9 +198,6 @@ static int pasta_spawn_cmd(void *arg)
> >  	if (mount("", "/proc", "proc", 0, NULL))
> >  		warn_perror("Couldn't mount /proc");
> >  
> > -	if (write_file("/proc/sys/net/ipv4/ping_group_range", "0 0"))
> > -		warn("Cannot set ping_group_range, ICMP requests might fail");
> > -
> >  	a = (const struct pasta_spawn_cmd_arg *)arg;
> >  
> >  	conf_hostname_len = strlen(a->c->hostname);
> 
> -- 
> Stefano
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson