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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

On Tue, Sep 08, 2026 at 05:32:37PM +0200, Stefano Brivio wrote:
> 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.

No, it's not.

Maybe I'll implement it if the spirit moves me, since I'm not really
beholden to practical priorities at the moment.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]