The kernel used on some autobuilders for the Debian PA-RISC port
can do "bwrap --ro-bind / / /bin/true", but not the bwrap invocations
made during the actual testing, which fail with "Creating new namespace
failed: Invalid argument". Make the trial bwrap invocation more like
what Flatpak actually does, so that these tests will hopefully be
skipped on such kernels.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876743
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
There are some changes needed to who automatic installation from OCI
repositories work that need to happen in the future. In order to not
"break" this support in a future stable release, we disable the adding
of oci repos unless the FLATPAK_ENABLE_EXPERIMENTAL_OCI environment
variable is set.
There is an important rofiles-fuse fix in this that
really mainly affects flatpak-builder, but we might as well
require it for flatpak too, so that we're sync:ed on the dependencies.
This is useful for Flatpak runtime and app authors who want to know
which features they can use when targeting a particular branch,
or if they do not have a particular branch in mind, what value they
should put in the required-flatpak field.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We have the same flags for flatpak_installation_update and we use
flatpak_dir_install from within FlatpakInstallation but always set
the no_pull/no_deploy flags to FALSE. Previously, passing
FLATPAK_INSTALL_FLAGS_NO_PULL and FLATPAK_INSTALL_FLAGS_NO_DEPLOY
wouldn't do anything because of that.
This has the unfortunate side effect of always returning an error
when FLATPAK_INSTALL_FLAGS_NO_DEPLOY is passed, because
flatpak_installation_install_full tries to get a FlatpakInstalledRef
for the flatpak when it is installed, but obviously it can't do that
since installing an app in an undeployed state doesn't "install" it
so much as just cloning it to the local repository.
As a result, when FLATPAK_INSTALL_FLAGS_NO_PULL is passed, the
FLATPAK_ERROR_ONLY_PULLED Will be set and the caller must respond
accordingly.
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).
