We used to only expose symlinks if the path to one was explicitly exposed,
like --filesystem=/symlink, but if you did say --filesystem=/symlink/dir, then
we would make /symlink be a regular directory in the sandbox tmpfs.
This means all exports are fully resolved, which allows use to remove the
workaround for symlinks that we had with sorting by "level".
We also add a FAKE_MODE_DIR, which is used to ensure the homedir is there,
created on tmpfs if needed only, while handling symlinks correctly.
This means that flatpak works well even if $HOME is on a symlink.
If the target of a direct bind, such as $home/.var/app/$appid/ is
a symlink, and the symlink contains absolute pathnames, then they
will not resolve correctly in the bwrap setup code due to the
fact that the final root is on /newroot, not /, so we resolve
the target paths before we call bwrap.
When we're resolving a symlink to see if the destination is visible, then
we have to actually append the rest of the path to look at the final
target, not just the intermediate symlinked directory.
When we hide a directory like that and it is a symlink we need
to hide the symlink target. Additionally, when we're checking
whether we need to mount the tmpfs we need to check that the
target is an actual dir, rather than a symlink to a dir.
Fixes https://github.com/flatpak/flatpak/issues/1032
This is taken in exclusive mode whenever we prune the repo. Anything
that is not protected against object disappearing from the repo can
take the lock in a shared mode to avoid running at the same
time as a prune operation.
The two operations the are problematic in this respect is
Pull:
* During the pull we see that some object we require is already available
and doesn't need downloading. We can't have it be removed before we
commit the transaction.
* During the transaction commit we're moving the object to the
repo, and they risk being pruned as unreachable until we have updated
the ref.
Deploy:
* Once we start checking out a particular ref we assume all the object
from it is reachable. If the ref is updated in parallel some object
can become unreachable and removed.
So, we take shared locks in these operations.
In the prune operation we take the block non-blocking, and skip
the prune entirely if some other operation is outstanding, because
we don't want to block a long time, and its likely that due to the other
operation we will run prune shortly anyway.
Note: Nothing protects the system-helper case when we download to a separate
repo. However, if there is a race we will get an error when importing this
to the system repo, so we'll never end up in an inconsistent state.
Previously we would still try to look up the remote information
to get the correct ref, this might not be supported in a case where
the user does not have an internet connection at the time that
applications are to be installed from the local repository.
This is the first step in increasing the startup performance for
font use in flatpak. Right now every app has its own cache
for the system font dirs, which means they must be fully regenerated
the first time the app starts.
With this we now expose the host system and per-use fontconfig caches
in the sandbox (read-only). This allows the sandbox to re-use caches
from the host, if the runtime fontconfig configuration is correct.
Unfortunately, this doesn't currently work, because the font caches
are looked up based on absolute paths to the font directories and they
are different in the host and the sandbox. There is some work in
progress to fix this in fontconfig here:
https://bugs.freedesktop.org/show_bug.cgi?id=101889
Previously, it was possible to enter ‘ ’ (a space) at a number prompt,
and it would be stripped, passed to is_number() (which would erroneously
return TRUE), then passed to strtol() and the return value used
unconditionally.
Fix that by fixing is_number() to return FALSE for the empty string.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We're scoping the deploy directory by the subpaths these days, so
we need to take that into account when finding the metadata file.
Fixes https://github.com/flatpak/flatpak/issues/1014
We pass FLATPAK_RUN_FLAG_NO_A11Y_BUS_PROXY when running the
sandboxed apply_extra_data script, because otherwise we run into
a crash due to the lack of an .flatpak-info file (and also, because
it is not needed).
Icons are really only a bunch of pngs, and the icon theme specification
has been stable since forever and never broke ABI. So, exposing the
host fonts should be pretty safe, comparable to the fonts that we
already expose.
This ends up being kind of important since a lot of things pick up the
icon theme from the host. In particular, it means that libXcursor can pick up
the correct cursor icons for the current cursor theme.
In case the summary file is GPG-signed, we already have other better
ways of verifying expectations around the installed ref.
If the deployed branch does not match xa.ref, simply warn instead of
aborting.
Based on a patch by Dan Nicholson <nicholson@endlessm.com>
Many flatpak commands only work on *.flatpak or *.flatpakref files, so
the bash auto completion showing every file is distracting and
unnecessary. This commit makes flatpak only show relevant files when
possible by using the "-G globpattern" compgen option.
As discussed in https://github.com/flatpak/flatpak/issues/975, it is
better to have the temporary repos for installing into the system repo
outside the home directory. This helps in the case when the home
directory is on a different filesystem. In particular it is more
likely to be on the same partition as the system repo in /var/lib.
There are multiple advantages if the two repos are on the same filesystem:
* Less chance of filling up the space on a filesystem that is not
the final target.
* It is possible to use fs operations like reflink or copy_file_range to
optimize the copies from the temporary repo to the system repo.
* The home directory is more often on NFS or other weird filesystem
type.
If a flatpakref has this set, for instance:
SuggestRemoteName=gnome-apps
Then flatpak install will ask if you want to configure
this as a "real" remote, rather than an origin remote (which
will only install that app).
This is useful when creating flatpakref files for remotes
that have multiple applications in them, such as e.g. flathub
or the gnome nightly builds. However, it should not be
set of one-application repositories.
* Get language list from AccountsService's dbus
Fixes issue #950
When xa.languages is not set in repo config, system installs will
get language list from AccountsService's dbus.
Lookup extra-data files as
~/.local/share/flatpak/extra-data/SHA256/FILENAME, Similar to files
downloaded in the .flatpak-builder directory.
For now, if a corresponding file exists, assume it's the full download
and read bytes from it. Then proceed to do the same checks as for the
bytes downloaded by Soup.
In the future this directory could be used to support resumed downloads
by storing partial downloads.
Factor out the pull options which are common to the collection-based and
non-collection-based code paths. This should make the code a little
easier to read.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When the summary file is updated, it’s kept in a local cache, so that
parts of flatpak can refresh it at will without network impact. We need
the same for the ostree-metadata ref, which stores the repository’s
metadata when collection IDs and P2P are used.
Implement that by comparing the checksum of the ostree-metadata ref from
the summary file and from the local repository. If they differ, it’s
almost certainly going to be because the summary file is advertising a
more up-to-date ostree-metadata ref, which we should pull. If they don’t
differ, there’s no need to try and update the ref. Therefore, this
chains off the caching of the summary file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add a sanity check and error message which prevents pulling the
ostree-metadata ref (the repository metadata) unless GPG verification is
enabled, as it needs to be signed to be trusted.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This isn’t really used internally, but will be used by gnome-software
for when it configures new flatpak remotes.
This is new public API, but is only declared if compiling with
--enable-p2p.
Includes some basic smoketests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to provide a transition path for repositories to add collection
IDs to themselves and propagate those collection IDs to clients’ remote
configurations, add another repo config key which controls whether the
repository’s collection ID is published. If xa.collection-id is set in
the repo’s published metadata, the client will update its configuration
to the given ID — but only if no ID is set already. This is a one-time
transition to prevent malicious repositories from remotely changing the
user’s configuration to associate their remote with a well-known
collection ID they don’t own.
Add a test for this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
To allow staged deployment of collection-ID-based repositories,
introduce the code to update a local repository configuration to add a
collection ID to it, based on updated metadata from the remote (as is
currently supported for other configuration keys).
As a security measure, this only allows updating the collection ID from
an empty to a non-empty value. We do not allow collection IDs to be
renamed (or a malicious repository owner could bypass the user’s manual
verification of the collection ID by changing it after the user has
configured an unrelated remote).
The idea is that most repositories should remain without collection IDs
for now, and use this mechanism to set their collection IDs in future,
once the functionality is more stable.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
