Build our own bubblewrap, and use it preferentially

On older or more paranoid systems like Debian <= 10, RHEL <= 7, SteamOS <= 2, Arch with the linux-hardened kernel and some Gentoo configurations, we have to rely on and use a setuid-root system copy of bwrap (supplied either as part of Flatpak, or as a standalone bubblewrap package). However, on newer or more featureful systems, we can use an unprivileged version of bwrap that is under our control.

The most recent bwrap release was made by a steam-runtime-tools developer, so we should be able to keep up with upstream bwrap :-)

In particular, this resolves #47 (closed) for the cases where we have any control over it (namely systems where unprivileged processes are allowed to create user namespaces). bubblewrap 0.5.0 also gives us better diagnostics when a --bind or other bind-mount fails, more reasonable permissions for mount points for non-directories, and fewer kernel warnings for XFS users.

We will have to be careful to test on Debian 10 or SteamOS 2 at least occasionally, to make sure the older-setuid-bwrap code path is still workable, until such time as we are ready to drop support for those distributions and require their users to upgrade.

I am not expecting you to review subprojects/bubblewrap! The changes relative to 0.5.0 are: part of "Add REUSE information for bubblewrap", "bubblewrap: Avoid a -Wjump-misses-init false-positive" and "bind-mount: Be more const-correct".

---

• Add 'subprojects/bubblewrap/' from commit 'b84704bb'

  (This is the bubblewrap v0.5.0 tag.)

• Add REUSE information for bubblewrap

• bubblewrap: Avoid a -Wjump-misses-init false-positive

  When building with -Wjump-misses-init as part of a larger project, gcc reports that we jump past initialization of cover_proc_dirs. This is technically true, but we only use this variable in the case where it's initialized, so that's harmless.

  However, we can avoid this altogether by making the array static and constant, which allows it to be moved from initialized data to read-only data.

  Forwarded: https://github.com/containers/bubblewrap/pull/447

• bind-mount: Be more const-correct

  When compiled with -Wwrite-strings as part of a larger project, gcc and clang both warn that we're assigning a string constant to a mutable struct member. There's actually no reason why it should be mutable, so make it const.

  Forwarded: https://github.com/containers/bubblewrap/pull/446

• pv-wrap: Move checking for bwrap into wrap-setup

• pv-wrap: Factor out test_bwrap_executable

• pv-wrap: Parameterize log level for test_bwrap_executable()

  When we try a local copy before falling back to a (possibly setuid) system copy, we won't want to log the first attempt as a hard failure.

• pv-wrap: Refactor handling of BWRAP environment variable

  When we try a local copy of bwrap before a system copy, we'll want to preserve the "user is always right" semantics here.

• pv-wrap: Use PRESSURE_VESSEL_BWRAP in preference to BWRAP

• pv-wrap: Use local copy of bwrap in preference to system copy

  The system copy might be older and less featureful, or might be unnecessarily setuid, so let's try to use a version that is under our control. If it works, great. If not, we can try a system copy, which we might have to use anyway (for example because it's setuid).

• pv-wrap: Build and use our own copy of bubblewrap 0.5.0

  This is considerably newer than the backport we have in scout, and includes fixes relevant to pressure-vessel, particularly for users of case-insensitive filesystems (#47 (closed), aka steam-runtime#326).

• pv-wrap: Include bwrap version in debug logs

• pv-wrap: Add a debug-level message when we find a suitable bwrap

  It looks a bit weird if we debug-log that our local copy was unsuitable, but then don't log anything when we find that a setuid system copy worked OK.

• pv-wrap: Log an info message if bwrap is setuid

  A setuid-root version of bwrap cannot use all of its features, so this is useful information.