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.
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.
Its pretty common to e.g. ship an icon theme bundled in the app,
but you then don't want to have a warning for every file.
So, instead make this a debug message.
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.
Alexander Larsson