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>
This means we can still test the old code path, even when a newer version
of AccountsService that will take the newer code path is available.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
