User and system installations is no longer a binary decision, so remove
this API to force explicit calls to either flatpak_dir_get_system_default()
or flatpak_dir_get_system_list() when dealing with system installations.
There will be a way to retrieve the list of all system installations,
not just the default one, so we rename this for backward compatibility.
Note that some (most?) of the places where we will be now using this
renamed function will likely have to migrate to using specific system
installations, but we don't have the necessary APIs yet so we do this
as an initial step to all the incremental changes that will come next.
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
This was manully checked in some places, which can now be dropped, but
also the places that didn't check it before were buggy and needed
to check this, so better just fail early.
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 you're building a runtime and have a base runtime with expected
extensions, fail to build if the actually installed extension is
partial (i.e. if it has a subdir specified).
Fixes https://github.com/flatpak/flatpak/issues/390
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 avoids an unnecessary call to flatpak_dir_modify_remote() or to
the system helper's D-Bus method ConfigureRemote, which also prevents
bothering the user to authenticate via PolKit for no reason.
Add logic in flatpak_dir_update_remote_configuration() so that the step of
configuring the local remotes after fetching the required date from the
server's summary file is performed via the system helper when present.
Note this will require the user authorizing the action by introducing
the password explicitly when asked, but this is necessary as updating
the local remotes configuration is something that can't be allowed
without explicit authentication.
It turns out that flatpak_dir_remote_fetch_summary can return TRUE,
yet leave summary_bytes NULL. The code further down does not deal
gracefully with summary_bytes being NULL, so error out early instead
of crashing.
We don't really need to create an origin remote if the same
uri is already there for an enumeratable remote, we can
just reuse that. Having multiple remotes for a single
repository just means we'll be downloading the summary file
multiple times.
Without this patch flatpak-remote-add (and anything else that uses this
section of code) segfaults if org.freedesktop.Flatpak.SystemHelper is
unavailable because it tries to cast an integer to a GDbusProxy.
