These make no sense, we don't want to modify the runtime, and
we can't create parent directories there anyway which can cause
issues like https://github.com/flatpak/flatpak/pull/433
When no session helper is available (e.g. running flatpak run from a
socket-activated service unit), we need to be extra careful before
making these two files appear inside the sandbox. Otherwise, if they
are not reachable on the host system (or just symlinks to non-existent
targets), flatpak won't be able to create the sandbox, which will fail
due to a "No such file or directory error".
https://github.com/flatpak/flatpak/issues/409
We already kind of support this by exposing the parent directory,
so this isn't really less secure, and you should not be able to
access it unless your user is allowed to anyway.
This lets it work during early setup phase when the new root is at
/newroot. This allows us to create things in /var/run with
e.g. --filesystem=/var/run/foo.
If the app is explictitly given access to a subdirectory of
one of the xdg config/cache/data directories, with read-write
(or create) access, then also bind-mount that directory
into the corresponding .var/app/$APPID directory.
This allows apps that want it to keep re-using global directories
for storing per-app information.
For instance, if your app uses "~/.config/foo" to store configuration
data, then you can use --filesystem=xdg-config/foo, which will look
for the directory, and if it exist, let the app access it, as well
as mirror the content in ~/.var/app/$appid/config/foo.
You can also use a ":create" to enforce the directory to be created
and thus always do the mapping.
This way you can't e.g. modify your or other applications
and runtimes. If you really need to to this, your
app can explicitly request access to this directory.
If we're specifying --filesystem=/some/path, where the final element
in the path is a symlink we need to special case this. We used
to rely on bubblewrap resolving the symlink for the source and
creating a bind mount directly to that, but this does not work
if the parent directory is already visible in the sandbox, because
we can't bind-mount on top of the pre-existing symlink.
Instead we detect this the symlink early, resolve the target and
bind mount in that, then we create a real symlink in its place.
However, that doesn't work if the paren't *doesn't* exist, so
we have to check for this and not create the symlink if it is
already going to be visible in the sandbox.
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 means you can do:
flatpak run org.freedesktop.Sdk
to get a shell in a sandbox with that runtime, but with an
empty /app.
You can also specify a particular runtime branch and command like so:
flatpak run --command=ls org.gnome.Platform//3.22 /
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.
Commit 352e761c0e started the trend
to print the errno error code when unable to open a file, make all
occurrences where files are opened print the same kind of message.
This is no longer needed, as we don't hard-require systemd --user.
We keep the opion there, but hidden in order to be backwards compatible
with old code that used this.
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.
The old location keeps working because we create a symlink.
The interesting part of this is that the sandbox now can't modify,
remove or replace the file, and it is in a fixed position. This means
that given a sandboxed pid, we can find this file as
"/proc/$pid/root/.flatpak-info".
This is very nice for two reasons:
* We can use this instead of the cgroup to find out if a pid is
sandboxed or not. This means we can drop the dependency on
systemd --user for this.
* We can get more information about the peer process that the
app id. For instance, we can see what permissions the sandboxed
app has.
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.
This directory is shared between all instances of the app, as well
as the host. In many ways this is similar to the ~/.var/app/$appid
directory, but the directory is guaranteed to not be persistent (/run
is on tmpfs), local to the host (not NFS), as well as nice support
for features like locks and mmap (due to being tmpfs).
This replaces all current callers of gs_file_ensure_directory with
equivalent code.
Actually, two instances were calling gs_file_ensure_directory with
FALSE, i.e. error out on EEXIST, but those cases seem fine with the
do-nothing-if-exists semantics.
This commit makes flatpak print a debug message (which only appears to
the user if the -v option is used) whenever a subprocess is launched.
This should make debugging easier, both for flatpak users and
developers.
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.
Alexander Larsson