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.
Currently flatpak-builder downloads the sources for all modules, even if
the --stop-at option prevents them from being built. This commit changes
the behavior so that we don't bother to download the ignored modules.
fi->fh is a uint64, and if we cast that directly to a pointer
on a 32bit arch then we get a warning, so lets first cast
to gsize, and then to pointer.
Should fix https://github.com/flatpak/flatpak/issues/173
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
We juse use g_file_new_for_commandline_arg instead of g_file_new_for_path.
This is somewhat related to https://github.com/flatpak/flatpak/issues/401
but doesn't actually handle the specific case of tilde.
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.
