flatpak run checks if there is any previous-ids for the app and
sees if there is a corresponding app-dir in ~/.var/app/ .
If so, it renames that app-dir to the new app-id and provides
a symlink from old app-id dir to new app-id dir, and exposes
these symlinks to the sandbox. The symlink is needed because even
though the XDG_DATA_DIR and other environment variables are set
to the new ID by flatpak run, the app itself could've stored
(eg in GSettings, or other files) paths which contained the old ID.
https://phabricator.endlessm.com/T23532Closes: #2775
Approved by: alexlarsson
end-of-lifed-with-rebase runs earlier in the transaction system than end-of-lifed, meaning it can modify the transaction for rebasing.
The new flatpak_transaction_add_rebase() function can then be used to apply the rebase if wanted.
Closes: #2775
Approved by: alexlarsson
With the new eol signal the list of ops can change during a resolve
operation, in which case we need to loop until things are stable.
Closes: #2775
Approved by: alexlarsson
When migrating an installed app from eos-apps to Flathub, it may have
had a different app ID (com.example.App) in eos-apps to the Flathub ID
(net.example.app). The migration logic arranges for previous-ids to be
set in the deploy file, and flatpak-dir.c preserves this across app
updates.
A user may have the app on their desktop or pinned to the taskbar under
its old ID, and the Shell uses X-Flatpak-RenamedFrom to update these to
the new ID. The migration logic arranges for the old ID to be added to
X-Flatpak-RenamedFrom at migration time; we need to also preserve this
across app updates.
Note that the Flathub version of the app may well have its own entries
in X-Flatpak-RenamedFrom. It is unlikely that these will overlap with
ours, but for neatness we take care to avoid adding duplicates.
https://phabricator.endlessm.com/T23845
Rebase 1.1.3 (T25194): Fix some minor merge conflicts
Closes: #2775
Approved by: alexlarsson
It is already removed in the system-helper, and the client doesn't
have permissions to delete it anyway (except for in the tests where
it was breaking things).
Closes: #2657
Approved by: alexlarsson
In the normal case, pass the full LIBEXEC path, and in the tests,
pass the path via the env var FLATPAK_REVOKEFS_FUSE.
Closes: #2657
Approved by: alexlarsson
If there is a pull failure in a child repo created on revokefs-fuse
mount, there is no way to go back to the system helper and notify
it to cleanup. Therefore, CancelPull is required on the pull failure
error path, so that the ongoing pull can be cleaned up nicely and
prevent any dangling mounts and subprocesses.
Closes: #2657
Approved by: alexlarsson
This adds a new helper method "GetRevokefsFd" which is responsible
for spawning the backend part of the revokefs filesystem. It takes care
of creating a cache location for the backing directory in repo/tmp.
This cache location is transferred over D-Bus to the client with the
other end socket fd.
The client on receiving the socket fd creates a mountpoint directory and
spawns the revokefs-fuse filesystem. It then creates a child repo for the
pull. In any case of failure, it fallbacks on the current code path
(which causes temporary duplication of files on disk).
The backing dir itself and all files written to it by the revokefs-fuse
backend process are owned by the "flatpak" user. After the pull in the
child repo is completed, it's ownership is then canoncalized with owner=root
and permissions as per bare-user-only in Deploy().
Now we have fulfilled all the criteria to hardlink the child repo into
the system one and avoid duplication. See [1].
If there is existing cache directory available in repo/tmp, it will be
mounted using revokefs-fuse for the current pull. Hence, it is possible
to recover the previous partial pull which might have failed due to some
error.
[1] https://github.com/ostreedev/ostree/pull/1776Closes: #2657
Approved by: alexlarsson
Make flatpak_dir_system_helper_call capable of dealing with a GUnixFDList
parameter and subsequently call g_dbus_connection_call_with_unix_fd_list_sync
for those methods.
Closes: #2657
Approved by: alexlarsson
For compatibility with libappstream we create a $origin ("flatpak")
subdirectory with symlinks to the size directories thus matching the
standard merged appstream layout if we assume the appstream has
origin=flatpak, which flatpak-builder creates.
See https://github.com/ximion/appstream/pull/224 for details.
Fixes https://github.com/flatpak/flatpak/pull/2779Closes: #2789
Approved by: alexlarsson
Currently a FlatpakTransaction object only operates on one installation,
but uses others (by default the system installations) for dependencies
such as runtimes. In addition to checking those dependency installations
for runtimes we check their configured remotes when deciding whether to
add a new remote as an origin for a flatpakref or as a runtime remote
for a flatpakref. This commit changes the behavior so that we only check
the installation being operated on to find out if a remote already
exists. This is the correct behavior in both cases: the origin remote
and the runtime remote. Otherwise the installation can error out when it
fails to find the runtime, or it can fail to respect the
SuggestRemoteName key which is supposed to dictate the name for the
origin remote.
One side effect of this is that a remote might be duplicated in the user
installation which already exists in the system installation, even if
the runtime it provides is already installed. But if you don't want
remotes in multiple installations you can just stick to using one
installation consistently.
Also, add a unit test for this in testlibrary.c (which required a bit of
refactoring).
Fixes https://github.com/flatpak/flatpak/issues/2758Closes: #2761
Approved by: alexlarsson
Rather than creating a real temp directory and
then commiting that we generate an in-memory mtree
which mostly refers to pre-existing icon file
objects, and then the newly created appdata xml.
Closes: #2753
Approved by: alexlarsson
It makes more sense to have this in flatpak_create_soup_session() so
every caller of that interprets the env var.
Closes: #2740
Approved by: matthiasclasen
Currently Flatpak has a few different implementations of helper
functions to download a URI using libsoup, but the best one seems to be
in common/flatpak-utils-http.c. So this commit deletes the others and
makes use of flatpak_load_http_uri() in place of download_uri() in a
few places. This has a couple consequences:
1) It means that we're now properly checking HTTP status codes rather
than assuming that the request was successful, in the install command,
remote-add command, and in FlatpakTransaction. This fixes an assertion
failure seen by a user when they tried to use a flatpakref URL that hit
a 404.
2) It means that in the places where we're using flatpak_load_http_uri()
we are only supporting http:// and https:// URLs not, say, file:// ones.
For the install and remote-add commands this was already being enforced.
For the handling of flatpakref files and bundles in FlatpakTransaction,
I believe it's just convention because it doesn't make much sense to
do anything else; this commit enforces that convention.
Also, add a unit test for the case of trying to install a flatpakref at
a URL that hits a 404 error.
Fixes https://github.com/flatpak/flatpak/issues/2727Closes: #2740
Approved by: matthiasclasen
Commit b20ee7e26 introduced a bug where flatpak_load_deploy_data()
returns NULL without setting @error in the case that there's a problem
reading the deploy file. I think this is causing a seg fault in
flatpak_installation_list_installed_refs() which tries to print the
error message after calling get_ref() (which indirectly loads the deploy
file).
I didn't personally verify that this fixes the GNOME Builder seg fault
that was reported, but it seems almost certain looking at the provided
stack trace, since get_ref() only returns NULL if
flatpak_dir_get_deploy_data() returns NULL, and that function clearly
sets the error pointer on failure except in flatpak_load_deploy_data().
I'm not sure why the deploy file doesn't exist (or is unreadable) for
the user who reported this seg fault.
Fixes https://github.com/flatpak/flatpak/issues/2717Closes: #2733
Approved by: matthiasclasen
Uncrustify has an option "nl_func_var_def_blk" which is supposed to
ensure there's a newline character between the block of variable
definitions and the rest of the function body, but it gets confused and
thinks that the first instance of "g_autoptr" or "g_auto" being used on
a variable is the start of the function body. So this commit removes
those extra newline characters and removes that option in uncrustify.cfg
so they don't get re-added the next time uncrustify is run.
Here's the command I used:
perl -0777 -i -pe 's/\n(\n\s*g_auto\()/\1/g' `git ls-tree --name-only
-r HEAD | grep \\\.[ch]$ | grep -v common/valgrind-private.h |
grep -v app/flatpak-polkit-agent-text-listener\\\.[ch]`
I ran it again with "g_autoptr" in place of "g_auto", and made a few
manual edits to add back the newline when the g_auto* was in the middle
of a function body rather than at the top.
Closes: #2715
Approved by: matthiasclasen
Edit uncrustify.cfg to add options to remove extra newlines near opening
and closing braces, and run uncrustify again.
Closes: #2715
Approved by: matthiasclasen
We do a one-time conversion of existing dconf user settings
into a keyfile in the apps XDG_CONFIG_DIR, where the glib
keyfile settingsbackend will look for it.
Closes: #2678
Approved by: alexlarsson
Whenever we use $XDG_RUNTIME_DIR and expose it somehow in the sandbox
we fully resolve the path, because if (as happens on gentoo for instance)
it contains /var/run -> ../run, then flatpak thinks we need to
add the /var/run symlink in the runtime even though we already
exposed that.
Closes: #2710
Approved by: matthiasclasen
As shown by CVE-2019-5736, it is sometimes possible for the sandbox
app to access outside files using /proc/self/exe. This is not
typically an issue for flatpak as the sandbox runs as the user which
has no permissions to e.g. modify the host files.
However, when installing apps using extra-data into the system repo
we *do* actually run a sandbox as root. So, in this case we disable mounting
/proc in the sandbox, which will neuter attacks like this.
For whatever reason, in the buildbot environment the TIOCGWINSZ
ioctl returns a 0x0 size, which causes a divide by zero. We
handle this by returning a default 80x24 size.
Closes: #2685
Approved by: alexlarsson
