System tests: new system-df and passwd tests

[edsantiago]

• New test for Make changes to /etc/passwd on disk for non-read only #6991 - passwd file is writable even when
  run with --userns=keep-id

• Enable another keep-id test, commented out due to Json output of podman images not affected by sorting options #6593

• New test for podman system df

Signed-off-by: Ed Santiago [email protected]

[edsantiago]

Tested the modifiable-passwd test against 77fb3d2 (commit before #6991 merged); confirmed that the new test fails with:

adduser: warning: can't create backup copy '/etc/passwd-': Cross-device link
adduser: Resource busy

[edsantiago]

I have a sinking feeling that this is related to CVE-2020-10713 and, sigh, I kind of bet all our CI is going to start failing:

[+0030s] Setting up grub-efi-amd64-signed (1.142.3+2.04-1ubuntu26.1) ...
[+0031s] mount: /var/lib/grub/esp: special device /dev/disk/by-id/google-persistent-disk-0-part15 does not exist.
[+0031s] dpkg: error processing package grub-efi-amd64-signed (--configure):
[+0031s]  installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 32
[+0031s] Processing triggers for systemd (245.4-4ubuntu3.2) ...
[+0031s] Processing triggers for man-db (2.9.1-1) ...
[+0033s] Processing triggers for install-info (6.7.0.dfsg.2-5) ...
[+0033s] Processing triggers for libc-bin (2.31-0ubuntu9) ...
[+0034s] Errors were encountered while processing:
[+0034s]  grub-efi-amd64-signed
[+0035s] E: Sub-process /usr/bin/dpkg returned an error code (1)
[+0035s] .
[+0035s] setup_environment.sh exit status: 100

[mheon]

LGTM

[rhatdan]

/lgtm
/hold
/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: edsantiago, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rhatdan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[edsantiago]

This now includes a fix for the Ubuntu upgrade problem. (Maybe "fix" is too strong a word, but anyway, CI is passing and should pass on any PRs rebased on this)

[TomSweeneyRedHat]

LGTM
and happy green test buttons. @mheon, want to do the honors?

[mheon]

/lgtm
/hold cancel

[cevich]

@edsantiago I think the CVE you found is a red-herring, or has since been fixed by a new package. The device not being available is odd, I'm not that worried about this because:

1. Installing updates at runtime is generally a bad idea for runtime stability - partially remove here, fully removed in Cirrus: Add python packages to images #7138
2. Runtime issues affecting boot will probably never impact our testing (reboots during testing unlikely to ever be supported or needed)
3. Building new VM images in Cirrus: Add python packages to images #7138 did not hit this issue (thankfully) - The VMs are effectively rebooted between the test_build..._task and verify_test_built..._task. A partitioning/boot problem would have shown up there.

On a fresh #7138 Chewbuntu 20 VM I see the same (1.142.3+2.04-1ubuntu26.1)package is installed, but perhaps more importantly I can see the partition:

root@cevich-ubuntu-20-podman-6530021898584064:/# dpkg -l grub-efi-amd64-signed
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                  Version                  Architecture Description
+++-=====================-========================-============-===============================================================
ii  grub-efi-amd64-signed 1.142.3+2.04-1ubuntu26.1 amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version, signed)

root@cevich-ubuntu-20-podman-6530021898584064:/# ls -la /dev/disk/by-id/google-persistent-disk-0-part15
lrwxrwxrwx 1 root root 11 Jul 30 16:03 /dev/disk/by-id/google-persistent-disk-0-part15 -> ../../sda15

So I think we'll be okay once my PR merges, but thanks for bringing the issue to me for a closer look.

[edsantiago]

@cevich thanks, I'm not worried about this one. I have to assume that Ubuntu botched their grub CVE fix, then corrected that situation with a followup package. The fix I pushed here (removing the apt command) is just added safety.