Given that originally this is mostly supposed to make ping work in "rootless containers" I'd wait for someone from that camp to chime in to find out whether they are on board with ignoring all the errors. (If I tried to push this I wouldn't be OK).

Other than that, I'm not sure how extensible this format is. I generally can imagine an RFE about ignoring some errors in containers only for example.

Given that originally this is mostly supposed to make ping work in "rootless containers"
I'd wait for someone from that camp to chime in to find out whether they are on board with
ignoring all the errors. (If I tried to push this I wouldn't be OK).

My motivation behind submitting #13141 was to get ping to work in rootless Podman containers, particularly the way they are set up by Toolbox to offer a development environment on Silverblue.

From that perspective, it seems enough to have net.ipv4.ping_group_range set on the host.

On my host:

[rishi@kolache ~]$ sysctl net.ipv4.ping_group_range
net.ipv4.ping_group_range = 0	2147483647

Inside a Toolbox container:

⬢[rishi@toolbox ~]$ sysctl net.ipv4.ping_group_range
net.ipv4.ping_group_range = 65534	65534
⬢[rishi@toolbox ~]$ ping -4 gnu.org
PING gnu.org (209.51.188.148) 56(84) bytes of data.
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=1 ttl=50 time=101 ms
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=2 ttl=50 time=100 ms
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=3 ttl=50 time=100 ms
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=4 ttl=50 time=100 ms
^C
--- gnu.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 100.122/100.391/100.634/0.429 ms

regarding the compat issue in the sysctl file format: note that upstream procps-ng still doesn't support /etc/sysctl.d/ iirc, it only reads /etc/sysctl.conf. So as long as that specific file doesn't do the "-" thing (and I don't think it should bother with that, as it's mostly the user's own configuration, all packages tend to use /usr/lib/sysctl.d/ drop-ins that, and the "-" is mostly something that is useful for keep things generically shippable in RPMs).

Also, we could probably file an RFE bug in procps-ng upstream requesting they also consider adding support for that.

I requested support for the "-" syntax here now:

https://gitlab.com/procps-ng/procps/issues/138

Let's see how that goes.

My motivation behind submitting #13141 was to get ping to work in rootless Podman containers, particularly the way they are set up by Toolbox to offer a development environment on Silverblue.

From that perspective, it seems enough to have net.ipv4.ping_group_range set on the host.

Got it. If we're talking about development environments where nobody is expected to debug why ping has stopped working at 3 am I think it's generally OK to let sysctl ignore all the errors everywhere. If it was something else I think it would be useful to make systemd-sysctl fail loudly so that it would be easier to figure out what went downhill as early as possible.

@poettering regarding the "-" syntax and my hypothetical RFE regarding ignoring some errors in containers only, in this particular case it would be kind helpful to do that. Are you planning to support something like "skip EINVAL for this thing in containers only"?

OK, let's merge this and to the wording fixups separately.

Got it. If we're talking about development environments where nobody is expected to debug why ping has stopped working at 3 am I think it's generally OK to let sysctl ignore all the errors everywhere. If it was something else I think it would be useful to make systemd-sysctl fail loudly so that it would be easier to figure out what went downhill as early as possible.

Hmm, I'd prefer not to ignore errors too aggressively, sometimes they might matter.

Note that net.ipv4.ping_group_range set on the host like we do now means it whitelists all groups, regardless how they are mapped. This means, if you then start a userns container, and don't set the sysctl you still get to enjoy the liberalization it introduced, since your own groups map to groups of those on the host, and hence your's are liberalized too.

So I think we should be all good in this regard, by ignoring the error in containers: the host will whitelist this for us anyway, and we couldn't whitelist anyway what the host didn't whitelist for us.

@poettering regarding the "-" syntax and my hypothetical RFE regarding ignoring some errors in containers only, in this particular case it would be kind helpful to do that. Are you planning to support something like "skip EINVAL for this thing in containers only"?

hmm, let's not get overboard with adding more and more conditons like this. I think our goal should be have everything as generic as possible and only do per-container exceptions where we really have to, and I think this case is not too strng...

after all, if we fail to write the sysctl on the host for an unknown reason and then ignore the failure, it really shouldn't matter much: what will happen then is that ping() will fail with EPERM for some folks, which isn't particular bad, and a clearly recognizable error anway. i.e. we don't break stuff where it was too late, all we do when writing fails and we ignore it is shift the error elsewhere.

hmm, let's not get overboard with adding more and more conditons like this.

I was kind of spitballing just to make sure that hypothetical extensibility (that hypothetically would make it easier to add some stuff without caring about containers) was covered and to figure out where this is going in general but to be honest I was hoping to hear something like this :-)