This allows bwrap to be built as a subproject in larger Meson projects.
When built as a subproject, we install into the --libexecdir and
require a program prefix to be specified: for example, Flatpak would use
program_prefix=flatpak- to get /usr/libexec/flatpak-bwrap. Verified to
be backwards-compatible as far as Meson 0.49.0 (Debian 9 backports).
Loosely based on previous work by Jussi Pakkanen (see #133).
Differences between the Autotools and Meson builds:
The Meson build requires a version of libcap that has pkg-config
metadata (introduced in libcap 2.23, in 2013).
The Meson build has no equivalent of --with-priv-mode=setuid. On
distributions like Debian <= 10 and RHEL <= 7 that require a setuid bwrap
executable, the sysadmin or distribution packaging will need to set the
correct permissions on the bwrap executable; Debian already did this via
packaging rather than the upstream build system.
The Meson build supports being used as a subproject, and there is CI
for this. It automatically disables shell completions and man pages,
moves the bubblewrap executable to ${libexecdir}, and renames the
bubblewrap executable according to a program_prefix option that the
caller must specify (for example, Flatpak would use
-Dprogram_prefix=flatpak- to get /usr/libexec/flatpak-bwrap). See the
tests/use-as-subproject/ directory for an example.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Keep a reference to the previous working directory and use it for the
umount.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #256
Approved by: cgwalters
In <https://github.com/projectatomic/bubblewrap/pull/101>, specifically
commit cde7fab7ec we started dropping
all capabilities, even if the caller was privileged.
This broke rpm-ostree, which runs RPM scripts using bwrap, and some
of those scripts depend on capabilities (mostly `CAP_DAC_OVERRIDE`).
Fix this by retaining capabilities by default if the caller's uid is zero.
I considered having the logic be to simply retain any capabilities the invoking
process has (imagine filecaps binaries like `ping` or
`/usr/bin/gnome-keyring-daemon` using bwrap) but we currently explicitly abort
in that scenario to catch broken packages which used file capabilites for bwrap
itself (we switched to suid). For now this works, and if down the line there's a
real-world use case for capability-bearing non-zero-uid processes to invoke
bwrap *and* retain those privileges, we can revisit.
Another twist here is that we need to do some gymnastics to first avoid calling
`capset()` if we don't need to, as that can fail due to systemd installing a
seccomp filter that denies it (for dubious reasons). Then we also need to ignore
`EPERM` when dropping caps in the init process. (I considered unilaterally
handling `EPERM`, but it seems nicer to avoid calling `capset()` unless we need to)
Closes: https://github.com/projectatomic/bubblewrap/issues/197Closes: #205
Approved by: alexlarsson
If you read the logs, ASAN gets confused by us using PID namespaces.
Perhaps we could figure out an API to change this later, but in
the meantime, let's disable leak checks.
We still get use-after-free detection.
Closes: #170
Approved by: alexlarsson
Previously we were just building in a container, now we actually run the test
script.
This explicitly does builds in a container still, and only installs
the bwrap binaries into the host's `/usr`. Down the line I think
we can enable better support for this model in redhat-ci.
Closes: #160
Approved by: jlebon
