As discussed in #5695, I think we're reaching a point where removing
Autotools is preferable to fixing it.
1.14.x continues to use Autotools, so platforms whose Meson version is
too old can stay on that branch until it becomes unsupported. We have
a very conservative Meson dependency (Ubuntu 20.04).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Before commits 97768cea and cb655ab3, we were upgrading GLib to a
post-Ubuntu-18.04 version before running tests, to work around a GLib
bug. We no longer need to do that now that we're running everything on
Ubuntu 20.04 or later.
Fixes: cb655ab3 "check.yml: remove glib260 ppa"
Signed-off-by: Simon McVittie <smcv@collabora.com>
These symbols were soft-renamed in libmalcontent 0.5.0 (released in
February 2020). We can probably now safely depend on that, and use the
renamed versions.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
flatpak_deploy_data_get_subpaths() returns a new array (of unowned
strings) and flatpak_dir_new_deploy_data() doesn't take ownership.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_option_context_add_group() takes ownership of the group that it's
given, so we can't also free it.
Fixes: fab0f8ed "test-context: Exercise some corner cases for merging filesystems"
Signed-off-by: Simon McVittie <smcv@collabora.com>
flatpak_close_fds_workaround() wasn't technically async-signal-safe,
because the requirement for sysconf() to be async-signal-safe was
removed in POSIX.1-2008.
It could also leave high fds open in some cases: in practice
sysconf(_SC_OPEN_MAX) returns the soft resource limit, but if our
resource limit has been reduced by an ancestor process, we could
conceivably still have fds open and inherited above that number.
We can fix this by using g_fdwalk_set_cloexec() with GLib >= 2.79.2,
or the backport in libglnx with older GLib. This uses close_range()
if possible, falling back to rummaging in /proc with async-signal-safe
syscalls.
Signed-off-by: Simon McVittie <smcv@collabora.com>
var_variant_dup_to_gvariant() returns a floating GVariant, and
g_variant_get_child_value() won't sink it, so we need to free it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_variant_get_child_value() returns a non-floating reference, so
g_variant_builder_add() will not sink it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is, strictly speaking, not allowed. On uncommon architectures like
CHERI, a pointer can be larger than a gsize.
This might also help to avoid AddressSanitizer losing track of
reachability, so that it won't think the array and its contents have
been leaked.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This allows g_autoptr destructors to run, avoiding memory leaks being
reported by AddressSanitizer; they would be harmless, since we're about
to exit anyway, but AddressSanitizer can't tell the difference between
an O(n) problem and an O(1) harmless "leak".
Signed-off-by: Simon McVittie <smcv@collabora.com>
1. For security context creation, only relies on WAYLAND_DISPLAY, do not
use WAYLAND_SOCKET since the file descriptor defined by WAYLAND_SOCKET
can be only consumed once.
2. Due to the incompatiblity between WAYLAND_SOCKET and the security
context, add a new permission --socket=inherit-wayland-socket
to limit the usage of WAYLAND_SOCKET to an opt-in feature. Only when
this flag is set, WAYLAND_SOCKET will be passed to the sandbox.
3. When WAYLAND_SOCKET is not inherited, set FD_CLOEXEC to avoid it to
be leaked the to sandbox.
Closes: #5614
* Provide fallback syscall wrapper for close_range()
* Backport g_closefrom() from GLib 2.79.2
* Backport g_fdwalk_set_cloexec() from Glib 2.79.2
* glnx_lsetxattrat(): Fix incorrect path argument
* Fix running `meson test` without first running `meson compile`
* Replace defunct mailing list with support forum
Signed-off-by: Simon McVittie <smcv@collabora.com>
Before the previous commit, this would normally work, but would fail if
we had FLATPAK_TEST_COVERAGE=1 in the environment.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As noticed on #5615, under normal circumstances, flatpak-run(1)
replaces itself with the bwrap process via execve(), and does not
close any fds that it might have inherited from its parent. This
allows for patterns like:
flatpak run com.example.App --in-fd=3 --out-fd=5 3<foo 5>bar
However, using execve() is annoying when trying to analyze code
coverage, because the coverage instrumentation does not get the
opportunity to write out its data during exit, so it is possible to
set FLATPAK_TEST_COVERAGE=1 to make flatpak run the app as a child
process and wait for it. This puts us on the code path normally used
for apps launched in the background by flatpak_installation_launch_full(),
which *don't* inherit arbitrary fds from their parent.
Detect this situation and use a different child setup function,
avoiding closing fds that we were meant to inherit.
Fixes: 88a928ea "run: Avoid execve() when measuring test coverage"
Signed-off-by: Simon McVittie <smcv@collabora.com>
Flatpak looks for extensions in all installations, but `flatpak info -e`
would display an error when an extension isn't present in the same
installation as the ref.
Also display the installation name for each extension.
We added this entirely unrelated apt repo to make CI work, but in fact
it now makes CI fail.
This reverts commit b6d5e20857b3587c212ce97de78cdbc2ef01d548.
In order to maintain a system over time update automatically removes any EOL runtimes that are unused.
This extends it to also remove any autopruned refs. In practice this means removing no longer used driver versions as the system is updated.
Closes#5261
Currently if the parental controls check can't connect to the system
bus, apps are not allowed to run. However, apps are also allowed to run
if the malcontent (or accounts-service) D-Bus services aren't available.
Since it's trivial to meet that requirement by starting a temporary
dbus-daemon and setting `DBUS_SYSTEM_BUS_ADDRESS` to use it, not being
able to access the system bus at all is no less secure.
This primarily affects flatpak running in a container where D-Bus is
generally not available.
Fixes: #5076
This fixes:
| Program /usr/bin/wayland-scanner found: NO
|
| ../git/common/meson.build:123:25: ERROR: Program '/usr/bin/wayland-scanner' not found or not executable
|
| A full log can be found at /home/flk/poky/build/tmp/work/corei7-64-poky-linux/flatpak/1.15.6/build/meson-logs/meson-log.txt
| ERROR: meson failed
At least for the openembedded build environment
Signed-off-by: Markus Volk <f_l_k@t-online.de>
