This way we never get confused about which part of the argument
is the permission suffix, which could be exploitable if you can
control the --filesystem calls such as with sandboxed Spawns.
This listens to org.freedesktop.portal.Flatpak and lets flatpak
sandboxes do flatpak specific things.
Initially this only allows access to "Spawn", which lets you start a
new copy of the current or latest version of the calling app,
optionally with sandboxing.
This allows the app to re-start itself with the latest version after
an update, and the sandboxing is useful for apps that want to manually
sandbox part of themselves.
You can also expose one or more subdirectories of
~/.var/app/$appid/sandbox/ to the app, read-write or read-only. This is
useful to communicate with the sandbox.
This runs the app in a very tight sandbox, with no access to anything
except /app and /run and some read-only host things like fonts and icons.
You can additionally add explicit permissions on the commandline,
like --share=network to actually grant some access.
This also sets $FLATPAK_SANDBOX_DIR to ~/.var/app/$appid/sandbox in the
environment.
This means if we undeploy something, but its still in use, then
we can find it later. This is interesting because it lets
us re-find it for spawning an instance of the same version.
So, if you run your instance with e.g. flatpak run --filesystem=/some/dir
you can now see this. This will be useful in the restart yourself
portal as we can then inherit such permissions.
This uses the new ostree feature at:
https://github.com/ostreedev/ostree/pull/1496
Note, this will only work with the current ostree master,
and does nothing on older versions.
Closes: #1533
Approved by: mwleeds
This commit adds the collection ID (if any) to the "Can't find ref"
error message produced by flatpak_dir_pull_untrusted_local(). This makes
the message more helpful if for example you run `flatpak update` when
some of the remotes are configured with the wrong collection IDs. It
also changes the wording to be consistent with other similar errors.
Closes: #1521
Approved by: mwleeds
As per https://github.com/flatpak/xdg-desktop-portal/pull/166, an access
check to a non-existant file should succeed if the parent directory
exists, and we have write access to it, because we can then just create the
file. This is needed for the "save" file chooser portal.
Closes: #1488
Approved by: alexlarsson
We set the Flatpak-Ref http header to the ref we're pulling, thus
allowing the server to log this for per-ref download statistics, as
otherwise the ref being downloaded is not visible in the log (only
the commit id).
Closes: #1487
Approved by: alexlarsson
repo_pull_one_dir() and repo_pull_one_local_untrusted() used to only
support pulling one directory at a time, but now support more than one,
so rename them so the names are less misleading.
Closes: #1475
Approved by: alexlarsson
Similarly to commit 272af0f8c, this commit makes sure the child repo
used by the system helper has an accurate summary file so it can be
pulled from. This time it's for the fetches of the ostree-metadata ref
and the appstream data.
This fixes a bug that occurs if a remote has a collection ID set and
uses the "branches" key as well. Under those conditions, `flatpak
remote-ls -d REMOTE` and `flatpak update --appstream REMOTE` can fail
with "Error pulling from repo: No summary found".
Until recently, the /ostree/repo/config in Endless contained a remote
that was shared between flatpak and ostree, which had "branches" set. So
that's a use case where this helps.
Fixes https://github.com/flatpak/flatpak/issues/1440Closes: #1478
Approved by: pwithnall
After pulling multiple refs into the child repo using P2P code, the
summary file in the child repo will be the one from the last remote
used. Since that remote might be a peer on the network or a USB drive,
it may not have the same set of refs as were pulled into the child repo.
This means that when the system helper tries to pull from the child repo
into the main repo it fails because the summary file is inaccurate.
This commit addresses the issue by regenerating the summary file in the
child repo after the pulls finish. This has to only occur on the P2P
code paths because non-P2P code uses the summary file and its signature
as the security check.
To check that this fixes the bug, I set up another computer on the local
network as an update server and made sure it had an updated
ostree-metadata ref for the remote I'm going to use. Then from this
computer with the patched flatpak I installed an app that's **not**
installed on the update server (all using collection IDs). Flatpak
fetched the app from the Internet, fetched the ostree-metadata ref from
the network peer, and then successfully pulled and deployed the app into
the system repo.
Fixes https://github.com/flatpak/flatpak/issues/1425Closes: #1476
Approved by: pwithnall
Apparently when I rebased https://github.com/flatpak/flatpak/pull/1314
to master, git cleanly applied the patch in a different place than it
was originally. Commit c5ab9e22b moved the find_remotes_async() call to
find_latest_rev(), so all that needs to be done is pass along the
checksum in check_for_update(). This way when you're trying to downgrade
something the specified commit will be searched for instead of the
latest one.
Fixes https://github.com/flatpak/flatpak/issues/1431Closes: #1435
Approved by: barthalion
Now that the search command is attempting to update appstream data for
all supported architectures, error messages get printed when it's
missing, which is often the case for i386. This commit changes
flatpak_dir_check_for_appstream_update() to only print an error if the
the appstream data for the host architecture is missing, but not if it's
a secondary architecture.
Closes: #1430
Approved by: alexlarsson
Before the 2018.2 release of libostree there was no way to specify
commit IDs when using find_remotes_async(). The latest commit is always
pulled, so flatpak apps can't be downgraded when collection IDs are in
use. Now that an option is provided by libostree this commit uses it,
and updates the minimum required version to 2018.2 when P2P support is
enabled.
The effect is that `flatpak update --commit=HASH APP` will work when APP
comes from a repository that has a collection ID configured.
Fixes https://github.com/flatpak/flatpak/issues/1309Closes: #1314
Approved by: pwithnall
The process was printing a line for every mismatching component id
in the xml for each app, which is starting to get very large log files
on flathub.
Closes: #1426
Approved by: alexlarsson
On atomic /home is a symlink to /var/home, so when we bind-mount
the persistent directories we need to early-resolve the symlinks
to avoid running into issues with /newroot.
In most cases we do this already by calling flatpak_bwrap_add_bind_arg,
but the persistent dir case did not, because that function required
the target to exist, and the persistent directoried might not.
However, these days flatpak_bwrap_add_bind_arg is fine if the base
dir doesn't exists but the target does, which is the case here,
so we can use it now.
This fixes e.g. steam: https://github.com/flatpak/flatpak/issues/1278Closes: #1422
Approved by: cgwalters
Check the return value of repo_get_remote_collection_id like we do
in other places. This doesn't really affect the result, because
we return NULL both before and after in the failure case, but
it makes things clearer.
This means use x11 if no alternative is present, and should be used
for applications that support both X11 and wayland, but want to be
sandboxed when running under a wayland compositor (but still want to
run under an X server).
Closes: #1416
Approved by: alexlarsson
Emacs needs ADDR_NO_RANDOMIZE during the build, and its possible
that other things do too. Also this make sense, as personality
seems like a syscall on the level of ptrace() which is already
in devel.
Closes: #1414
Approved by: alexlarsson
This commit breaks out the code in flatpak_dir_check_for_update() that
finds the latest revision of a ref into its own function and uses it in
flatpak_dir_check_for_appstream_update(). This allows appstream updates
to work even for offline machines.
Fixes https://github.com/flatpak/flatpak/issues/1404Closes: #1397
Approved by: alexlarsson
Before doing an update, flatpak fetches remote repo metadata to find
related refs and other information. But after fetching the metadata
flatpak fetches the remote summary to get the checksum that was just
fetched, which can fail if the computer is offline. So instead get the
checksum by reading the local repo, which has the side benefit of
eliminating a race condition (the summary being updated right after the
fetch happens).
Closes: #1397
Approved by: alexlarsson
In the last step in a LAN app update when the system helper is called to
deploy the update, there's a call chain to pull from the temporary child
repo:
handle_deploy() ->
flatpak_dir_pull_untrusted_local() ->
repo_pull_one_local_untrusted() ->
ostree_repo_pull_with_options()
But since repo_pull_one_local_untrusted() isn't aware of the existence
of collection IDs, it doesn't pass a collection ID along to libostree
and sets gpg-verify-summary to true. This leads to the error "GPG
verification enabled, but no summary.sig found" because P2P code paths
don't use summary signatures.
Add the appropriate ostree pull options to
repo_pull_one_local_untrusted() so that P2P updates work when the
system-helper is used.
Fixes https://github.com/flatpak/flatpak/issues/1388Closes: #1397
Approved by: alexlarsson
Currently P2P flatpak app updates aren't working when
the system installation is being used (but they work for the user
installation). This is because there's a
flatpak_dir_remote_fetch_summary() call in flatpak_dir_update() which
fails if the machine isn't connected to the Internet. And in fact we
don't need to pull the summary from the system remote, we need the one
from the temporary P2P remote, and that gets pulled as a result of the
flatpak_dir_pull() call to get the ref because
OSTREE_REPO_PULL_FLAGS_MIRROR is used. So this commit changes
flatpak_dir_update() to avoid fetching the system remote summary fetch
when P2P support and collection IDs are being used.
Similar logic applies to flatpak_dir_install() and
flatpak_dir_update_appstream() (although P2P appstream updates don't
seem to be working yet).
This is a partial fix for https://github.com/flatpak/flatpak/issues/1388Closes: #1397
Approved by: alexlarsson
repo_get_remote_collection_id() already squashes empty ("") collection
IDs into NULL, and ignores the collection ID when P2P support isn't
enabled. So use that helper function in
flatpak_dir_get_remote_collection_id() for consistency. At the moment
that function is only used in tests, so this doesn't immediately affect
anything.
Closes: #1411
Approved by: alexlarsson
Instead of just assuming the default pulseaudio socket we look
at the same environment and config files that pulseaudio does.
This does not currently look at the X11 properties.
This is a cleaned up and rebased version of https://github.com/flatpak/flatpak/pull/1208Closes: #1410
Approved by: alexlarsson
This is now in xdg-desktop-portal. We keep a version of the document
portal dbus XML so that we avoid weird build dependencies.
Flatpak itself is technically not dependent on the document portal,
but it is very much recommended that you use it.
Closes: #1398
Approved by: alexlarsson
The document portal is essentially optional, so avoid spewing errors
if it is not available, but also report this nicer with -v.
Closes: #1387
Approved by: alexlarsson
If a ref can't be found in a remote it could be because it's truly not
there or it could be that the collection ID configured locally doesn't
match the one on the remote. This commit improves the "No such ref"
error message to include the collection ID in two more locations in
flatpak-dir.c to make it easier to debug "wrong collection ID" errors.
Closes: #1384
Approved by: pwithnall
For security, only root can downgrade flatpaks in the system
installation. However, the error message explaining this when a normal
user attempts a downgrade was removed in commit 44cf5076f. This commit
adds back the error message.
Since the current behavior is for a downgrade by a non-root user to fail
with the message "No updates", this commit doesn't fix a security issue.
It's purely about usability.
Fixes https://github.com/flatpak/flatpak/issues/1303Closes: #1366
Approved by: alexlarsson
It’s somehow possible (I haven’t investigated how) for
flatpak_dir_setup_extra_data() to be called before the main keys (such
as `outstanding-fetches`) are set on a new OstreeAsyncProgress during a
flatpak_dir_pull() call with no OstreeAsyncProgress object provided by
the caller.
This means that an OstreeAsyncProgress with only the extra-data keys
would be passed through to
ostree_repo_pull_default_console_progress_changed(), which would cause
an assertion failure when it tried to read the `outstanding-fetches`
key.
Avoid that by not calling
ostree_repo_pull_default_console_progress_changed() until
`outstanding-fetches` is set.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1361
Approved by: alexlarsson
