This tests that we pick a new version, that the old is uninstalled
and that when running it old data is migrated.
Closes: #2775
Approved by: alexlarsson
This copy-pastes a lot of internal code from flatpak-dir.c to mess with
the deploy file. It could be made a lot shorter...
https://phabricator.endlessm.com/T23845Closes: #2775
Approved by: alexlarsson
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
This lets you rebase an app, as well as other matching refs (OLD is
used as a prefix match) such as locale and debug extensions.
r your changes. Lines starting
Closes: #2775
Approved by: alexlarsson
Application installers want to have access to
these fields to present repositories to the user,
so store them in our repo config, using xa.
prefixed keys.
Closes: #2812
Approved by: alexlarsson
Historycally the system helper has been running in a generic
unconfined_service_t domain. However, this caused problems with the
new revokefs support, because passing the revokefs unix domain socket
over the system bus got it kicked of the bus, because to do this
dbus-daemon needs rw rights to the socket.
So, this module creates a custom domain flatpak_helper_t, which
allows us to add special permissions to dbus-daemon to allow
access to its sockets.
The domain is otherwise uncontained just like before. I did try
to make it contained, but that is a lot of work as the permissions
it needs are very complex.
Note to packagers on selinux systems, for flatpak to work well
you need to install this module and relabel the system-helper
binary.
In my testing on fedora I used something like this:
%post
%selinux_modules_install %{_datadir}/selinux/packages/flatpak.pp.bz2
%postun
if [ $1 -eq 0 ]; then
%selinux_modules_uninstall %{_datadir}/selinux/packages/flatpak.pp.bz2
fi
With these new files:
%{_datadir}/selinux/packages/flatpak.pp.bz2
%{_datadir}/selinux/devel/include/contrib/flatpak.if
Closes: #2657
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
When installing via the child repo we now strip the permissions early
so the import will fail instead of import and then canonicalize.
Either is ok, as nothing should be non-canonical in real life.
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
This is necessary so as to not leave the revokefs backend around
when the system-helper exits abruptly (e.g. OOM killer). It would
be a vulnerability if revokefs backend continues to live even after
the system-helper is killed as it might lead to write access to the
underlying directory.
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
