With older GLib, it's provided by libglnx, but with newer GLib, we need
to include the correct header.
Fixes: 7b1cd206 "Replace flatpak_close_fds_workaround() with g_fdwalk_set_cloexec()"
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>
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>
To make indentation work with less effort. The modeline was copied from
libostree with minor modification and the .editorconfig from GLib.
The advantage of having both a modeline and an editorconfig is we can
work out of the box on more editor setups, and the modeline allows us to
specify the style with a lot more fine grained control.
Recent Meson versions have warnings if you add the subprojects
directory as an include path, because the way Meson wants to consume
subprojects is by the subproject's build system producing a Meson
dependency object that encapsulates its include directory. Flatpak
doesn't have a Meson build system yet, but I'm working on that.
libglnx seems to be set up to have the libglnx directory be its include
path instead: for example, ostree (by the author of libglnx) already
uses "libglnx.h" or <libglnx.h> everywhere. Do the same here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Like $XDG_RUNTIME_DIR/app/$FLATPAK_ID, this is shared between all
instances of the app, except for subsandboxed instances created by
flatpak-spawn --sandbox or equivalent. Unlike
$XDG_RUNTIME_DIR/app/$FLATPAK_ID, it does not exist at an equivalent
path on the host and in the sandboxed app.
Resolves: https://github.com/flatpak/flatpak/issues/4120
Signed-off-by: Simon McVittie <smcv@collabora.com>
If XDG_RUNTIME_DIR is under app control, as it will be with #4120, we
don't want to be mounting pieces of filesystem directly into it, because
that will mean that the app could create a symlink that will cause us
to create a mount point for it at the target of the symlink, potentially
elsewhere in the host filesystem.
Instead, we mount them in /run/flatpak, which is a per-instance
directory entirely controlled by Flatpak; and then create (relative)
symlinks in XDG_RUNTIME_DIR, pointing into /run/flatpak.
In this commit, we still know that the XDG_RUNTIME_DIR is a
per-instance tmpfs, so we can safely create the symlinks using
the --symlink option. In a subsequent commit this will change to
creating them in a shared XDG_RUNTIME_DIR, if any.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This has no practical effect (assuming environment variables are unique),
but it makes it easier to find an environment variable of interest
in a very long bwrap command-line.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes them easier to deal with when debugging. Otherwise, it's easy
for the bundled arguments to wrap across 50 or more lines, and with
linebreaks in arbitrary positions that becomes very hard to read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids some of them being filtered out by a setuid bwrap. It also
means that if they came from an untrusted source, they cannot be used
to inject arbitrary code into a non-setuid bwrap via mechanisms like
LD_PRELOAD.
Because they get bundled into a memfd or temporary file, they do not
actually appear in argv, ensuring that they remain inaccessible to
processes running under a different uid (which is important if their
values are tokens or other secrets).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: https://github.com/flatpak/flatpak/security/advisories/GHSA-4ppf-fxf6-vxg2
flatpak_bwrap_bundle_args() for some reasons does:
data = g_new (gchar, data_len);
*data = 0;
And then it starts copying in the data into the allocation, overwriting
the initial 0. If data_len is 0 this causes a write past end of
allocation, so just drop the second line above.
It turns out d91660fe2a accidentally
broke the inheritance of non-stdin/out file descriptor into children
of "flatpak run" which broke the fd passing in the flatpak spawn portal.
This reverts that, allowing all fds not specifically marked as CLOEXEC
by other means to be inherited into the child.
Fortunately the regression was not in any stable release.
As per https://gitlab.gnome.org/GNOME/glib/merge_requests/490
there is a bug in glib < 2.60 where g_spawn_* can sometimes deadlock
due to using malloc in the child func to close fds.
We work around this in places where the code is (potentially) threaded
by passing glib flags to leave fds alone and then do a very naive
(but safe) fd cloexec loop ourselves.
Uncrustify has an option "nl_func_var_def_blk" which is supposed to
ensure there's a newline character between the block of variable
definitions and the rest of the function body, but it gets confused and
thinks that the first instance of "g_autoptr" or "g_auto" being used on
a variable is the start of the function body. So this commit removes
those extra newline characters and removes that option in uncrustify.cfg
so they don't get re-added the next time uncrustify is run.
Here's the command I used:
perl -0777 -i -pe 's/\n(\n\s*g_auto\()/\1/g' `git ls-tree --name-only
-r HEAD | grep \\\.[ch]$ | grep -v common/valgrind-private.h |
grep -v app/flatpak-polkit-agent-text-listener\\\.[ch]`
I ran it again with "g_autoptr" in place of "g_auto", and made a few
manual edits to add back the newline when the g_auto* was in the middle
of a function body rather than at the top.
Closes: #2715
Approved by: matthiasclasen
We generate various configuration files for each sandbox instance,
and expose them to the sandbox using flatpak_bwrap_add_args_data,
which in the end passed --bind-data to bwrap. These files are not
sensitive or shared, but it still doesn't really make sense for
the sandbox to allow them to be modified, so lets switch them
to --ro-bind-data.
This affects these files in the sandbox:
$HOME/.var/app/$APPID/config/user-dirs.dirs
/etc/group
/etc/ld.so.conf
/etc/passwd
/etc/pkcs11/modules/p11-kit-trust.module
/etc/pkcs11/pkcs11.conf
/etc/timezone
/run/flatpak/ld.so.conf.d/*.conf
/run/user/$UID/pulse/config
/run/user/$UID/Xauthority
This just keeps the fd alive until the FlatpakBwrap is freed, it
doesn't actually pass it on to the child.
We want to use this to keep a file lock held until the sandbox has
started where it takes over the lock.
Closes: #1730
Approved by: alexlarsson
