Backuppc autopkgtest fails doing ping6 due to 'Operation not permitted'

[Bryce Harrington]

https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/armhf/b/backuppc/20210715_161819_ec8d5@/log.gz

+ echo Performing a full backup
+ sudo -u backuppc -H /usr/share/backuppc/bin/BackupPC_dump -v -f localhost
Performing a full backup
cmdSystemOrEval: about to system /bin/ping6 -c 1 localhost
cmdSystemOrEval: finished: got output /bin/ping6: socket: Operation not permitted

CheckHostAlive: first ping failed (512, )
no ping response
+ result=1
ERROR: Full backup failed, exit status was 1
+ check_status 1 Full backup
+ local status_code=1
+ local msg=Full backup
+ [ 1 -ne 0 ]
+ echo ERROR: Full backup failed, exit status was 1
+ exit 1

We've not been able to reproduce this synthetically on armhf; ping6 seems to work fine. newpid is seeing a similar 'Operation not permitted' error on armhf too, although it's with the ping command rather than ping6 (see https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/armhf/n/newpid/20210714_044712_180ac@/log.gz).

The context of the test is using ping as a diagnostic to verify another system is present. Thus, the problem is not highlighting a bug in the backuppc code itself, but in the testing environment or test implementation.

[Bryce Harrington (bryce)]

Only thing I found searching debian/upstream was this bug:

https://github.com/backuppc/backuppc/issues/177

which suggests reinstalling iputils-ping resolves it.

[Bryce Harrington (bryce)]

One other guess:

<mwhudson> some seccomp nonsense maybe?
<bryyce> mwhudson, could be; the internet is rife with idea variety here
<mwhudson> i mean the fact that it only happens on armhf and armhf is the only arch that runs in a container is unlikely to be a coincidence
<bryyce> mm, good point
<mwhudson> but i would guess the containers are privileged so eh i don't know

[Bryce Harrington (bryce)]

Sergio found that reinstalling iputils-ping did indeed seem to lead to success.

I didn't spot a matching iputils bug report, though this one feels close:
https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1302192

[Sergio Durigan Junior (sergiodj)]

Thanks for the report, Bryce.

As discussed, here is the proposed debdiff that fixes the problem on armhf. It is not entirely clear why reinstalling iputils-ping makes the test pass, but after preparing a PPA:

https://launchpad.net/~sergiodj/+archive/ubuntu/backuppc-armhf/+packages

and running autopkgtest on it, I verified that it works.

I thought about submitting this to Debian, but now I'm not so sure it's going to be useful for them.

[Launchpad Janitor (janitor)]

This bug was fixed in the package backuppc - 4.4.0-3ubuntu1

---------------
backuppc (4.4.0-3ubuntu1) impish; urgency=medium

  * d/t/smb-backup: Reinstall iputils-ping in order to workaround a ping6
    suid problem on armhf (LP: #1936437).

 -- Sergio Durigan Junior <email address hidden> Thu, 15 Jul 2021 18:21:11 -0400

[Paride Legovini (paride)]

Some more info on this bug:

 * In >=Focal ping6 is a symlink to ping, so ping may fail
   in the same way.

 * ping gets the "raw socket" permissions it needs via a
   capability:

   $ getcap /usr/bin/ping
   /usr/bin/ping cap_net_raw=ep

   No need for suid bits.

 * I downloaded ubuntu-20.04-server-cloudimg-armhf.img from [1],
   mounted it with using qemu-nbd and verified that ping has the
   right capability: it does. However I'm not 100% sure that's
   the image used to deploy the autopkgtest testbed systems.

 * ping doesn't even need that one, provided that the GID
   running ping is in this range:

   sysctl net.ipv4.ping_group_range
   net.ipv4.ping_group_range = 0 2147483647

   Note: this also affects IPv6.

[1] https://cloud-images.ubuntu.com/releases/focal/release/

[Brian Murray (brian-murray)]

The Hirsute Hippo has reached End of Life, so this bug will not be fixed for that release.

[Paride Legovini (paride)]

Version 4.4.0-5 didn't need the "reinstall iputils-ping" delta so apparently this got fixed somewhere else (thanks Sergio for figuring this out and syncing). The Debian d/changelog has:

backuppc (4.4.0-5) unstable; urgency=medium

  [ Simon McVittie ]
  * debian/rules: Specify canonical path to ping6. (Closes: #992647)

That Debian bug is about a *different* issue, but maybe using the canonical path somehow made a difference, who knows.

Speaking of Focal (the only open task here): we should verify if the same change fixes the issue there. The autopkgtest is hinted there, so this is non-blocking. I'm setting the Focal status to Incomplete for now as the whole issue is in my opinion not well understood.