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

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 8 Sep 2026 16:24:04 +1000
David Gibson <david@gibson.dropbear.id.au> 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 <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.

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

-- 
Stefano