This environment variable has been used for a while; it's just
undocumented. Copy some information from a comment in flatpak-dir.c.
Closes: #2841
Approved by: matthiasclasen
As seen in https://github.com/flatpak/flatpak/issues/2829,
the system-helper crashes while trying to access an as
parameter as s. Looking at the likely culprits for this,
I find that the permission check for Deploy has an off-by-one
error where it tries to get the installation, but
passes the offset for the previous_ids parameter.
Closes: #2831
Approved by: matthiasclasen
On some systems we can't make use of FUSE, especially on the same
locked-down systems where distribution packages are typically built.
For example, official Debian autobuilders (buildds) are configured to
disallow module loading after boot has finished as a form of security
hardening, some build chroots don't have a valid /etc/mtab, and Docker
containers give us uid 0 but not CAP_SYS_ADMIN.
These checks are taken from libostree.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2824
Approved by: matthiasclasen
This follows the same logic as the system bwrap.
Otherwise, build-time tests will fail when we are using a system
xdg-dbus-proxy and not compiling our own (the symptom is that testlibrary
hangs).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2823
Approved by: matthiasclasen
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
Matthew Leeds