Instead of inheriting the portal's environment when spawning a
subsandbox using flatpak-run, inherit the environment in which
flatpak-run was originally executed for the parent instance.
This means that environment variables that affect the sandbox setup
of the parent instance now also propagate to the setup of
subsandboxes, including "FLATPAK_GL_DRIVERS".
Closes: https://github.com/flatpak/flatpak/issues/5278
This function can be used to parse environment variable blocks in
"env -0" format from a buffer. It performs a few format checks during
its parsing and returns an error if an issue is found.
When successful, it returns a string array containing each individual
environment variable parsed from the buffer, in the same format as
the return value of g_get_environ().
The implementation of this function is based on
flatpak_context_parse_env_block().
Unlike the instance directory, whose directory structure is
considered public API and is mounted in the sandbox, the private
instance directory is meant to hold private data or metadata about
an instance for use by internal components.
The private instance directory is not meant to be shared with any
external component, and provides no guarantees about its structure
or contents.
While the public instance directory is named "<instance-id>", the
private instance directory is named "<instance-id>-private". Both the
public and private instance directories share the same parent
directory.
The private instance directory relies on the same lock file as the
public instance directory, and both are garbage-collected together.
To align with work in D-Bus, the security-context's sandbox engine names
are now supposed to follow the reverse-DNS style.
This change should be fine because there has not been a release of
flatpak with security-context support, yet.
These environment variables inform the Vulkan loader on where to find driver files.
Since they typically point to locations on the host filesystem, any application that
attempts to load Vulkan within the flatpak sandbox would break with these set.
The tests/make-test-runtime.sh scripts sets '-e' in lieu of
implementing useful error checking, but doesn't actually check
if the programs it uses exist in the first place; and aborts
silently when they're not available.
It is more useful to warn about them, and stop execution earlier.
This leaves some leftover files, but arguably that's better than
leaving leftover files AND people scratching their heads.
Warn about missing required programs.
Related: https://github.com/flatpak/flatpak/issues/5020
Doing so adds the following flags to the openat() call:
O_RDONLY | O_NONBLOCK | O_NOCTTY
And removes the following flag: O_PATH
Also let libglnx handle the error message formatting.
Use architecture instead of id in call to
flatpak_dir_load_appstream_store ().
Without this, remote-info does not show AppStream metadata.
Fixes: adb3b61f "decomposed: Return FlatpakDecomposed from flatpak_dir_find_remote_ref()"
There was already a timeout set using `CURLOPT_CONNECTTIMEOUT`, but that
only affects the initial connection. Once a HTTP connection is
established, the timeout is ineffective.
That means that once a HTTP connection is established, there is no bound
on the length of time a download can take. Sometimes, downloads drop to
very low speeds (for Networking Reasons) and we need a way to give up on
a download if that happens.
So, set a low speed limit of 10KB/s for 60s. If a curl download goes
more slowly than this, it will be considered timed out, and the
`CURLE_OPERATION_TIMEDOUT` code path will be taken.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: https://github.com/flatpak/flatpak/issues/5519
The `code` argument to wayland-scanner is deprecated in favour of
`private-code`, which marks the symbols as private, avoiding them
leaking into the ABI of `libflatpak.so.0`.
`private-code` was new in wayland-scanner 1.15, which is available in
relatively old LTS distributions like CentOS 7, Debian 10 and
Ubuntu 18.04, and is much older than wayland-protocols 1.32.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is only needed in flatpak-run-wayland.c, so we don't need it when
linking ancillary daemons that don't need any of flatpak-run, such as
the portal, session helper, system helper and OCI authenticator.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was new in GLib 2.60, but libglnx now provides a backport, so we
can use it unconditionally.
We still need a wrapper because g_strv_equal() is not NULL-safe, but
it's a very thin wrapper now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Our only code that is conditional on the libappstream version wants
version 0.14.0, which conveniently is exactly the version that
introduced AS_CHECK_VERSION.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These functions are to do with being an interactive, terminal-oriented
CLI/TUI, so it would be inappropriate for library code in libflatpak
to call them, and it would also be inappropriate for daemons like the
session and system helpers to call them.
In fact all calls to these were already isolated to app/, so we can
easily move the terminal-related utilities themselves into app/.
As well as shrinking libflatpak, this makes it obvious that the system
helper does not actually need to call flatpak_disable_fancy_output():
it does not link any code that would be affected by that API call.
Signed-off-by: Simon McVittie <smcv@collabora.com>
By giving the context a bit more knowledge of which directories Flatpak
uses for what, we can stop it from depending on the dir/run modules,
which themselves depend on FlatpakContext.
Signed-off-by: Simon McVittie <smcv@collabora.com>
