If you do something like:
flatpak build --talk-name=org.foo.Bar appdir
Then we now spawn a dbus proxy for the app.
However, we don't do this by default, even if the
runtime or the app metadata allows this, because
we want builds to normally be disconnected from
the build host.
If your extension points set this, then each extension will have
the corresponding subdirectory added to LD_LIBRARY_PATH.
We also support a priority property in the ExtensionOf group
in the extensions themselves to set the search order.
We make /etc just a symlink to /usr/etc when we're building a runtime
and /etc is supposed to be writable. Otherwise the bind-mount we
normally have there don't allow use to replace existing files in /etc.
This allows you do do something like
flatpak build-finish --add-policy=subsystem.key=v1 --add-policy=subsystem.key=v2
Which maps to this metadata keys:
[Policy subsystem]
key=v1;v2;
You can also --remove-policy to remove values from a key.
The policy values are parsed from the app and runtime metadata, and
are overridable by per-app overrides and on the command line, however
the values are never used by flatpak. They do end up in the flatpak-info
file for the running application though, so external agents can look
at them.
These
This adds a new "multiarch" feature which allows bundling e.g. 32-bit
binaries to be run in a x86_64 environment. By default, the seccomp
filter is configured to allow only the native architecture. When the
"multiarch" feature is enabled, the filter will be configured to allow
running binaries of additional architectures supported. For x86_64, this
allows x86 32-bit binaries; and for Aarch64, allows 32-bit ARM binaries.
Application bundles can use the feature e.g. in order to ship 32-bit
binaries alongside with a mostly-64-bit application. This is particularly
interesting when for applications that might launch themselves prebuilt
programs for which 64-bit versions do not exist. For example, the Steam
application is available as a 64-bit executable, but some of the games
available are 32-bit only. A Flatpak bundle for the Steam application
with "multiarch" enabled is able launch the 32-bit games -- without the
feature enabled, the seccomp filter would prevent them from running.
Multiple-architecture support is enabled by adding the "multiarch" value
for the "features" key in the metadata file for a Flatpak:
[Context]
features=multiarch;
The corresponding "--allow=multiarch" command line option is supported
in "flatpak build-finish" as well.
This has two advantages. First of all (and most important) it
lets us put a /.flatpak-info file in it, so that the dbus peers
it talks to have the right "source" app id and sandboxed status.
Secondly, it lets us run the bus with readonly access to things,
thus being somewhat more secure.
The info file is always standalone, as it never needs to stack on top
of another context. This means we can remove all "negative" attributes
such as "shared=!network", making it easier to parse this file.
This enables support for ptrace and perf for the app, similar
to what run -d manually gave you before. This is nice to be
able to package an app like gnome-software.
Arrange for stdout and stderr to be redirected to the systemd
journal, before exec'ing bwrap. This is under the control of
a pair of run flags. By default, we try to be smart and only
redirect if stderr is not a tty.
This regressed when we moved to bubblewrap. We need to always use
a direct bind for building, because it may not necessarily happen
in a real user session where the session-helper works.
We need to keep all the fd:s needed for bubblewrap alive, so
neuter g_spawn_async:s close of fds and do our own.
Also, we need this so these fds can be closed in the launching app.
Alexander Larsson