We add an error signal to Transaction that the calle (cli) handles. It
decides what to do with the error and whether to continue or abort.
A new error ABORTED is returned from flatpak_run() to indicate
that it errored out because you chose to abort. We also add a new
error SKIPPED that we use to report that some operation is skipped
(due to earlier errors).
This also means we remote the stop_on_first_error argument
from flatpak_transaction_run() as this is now controlled by
the caller.
This reworks the dbus proxy to be more in line with the API proposed at
https://bugs.freedesktop.org/show_bug.cgi?id=101902
In particular, it makes the filtering language more expressive. You
can now filter both calls and broadcast recieves, and filters now work
with wildcarded object paths, bus names and interfaces
(BUS_NAME_IS_SUBTREE, OBJECT_PATH_IS_SUBTREE and empty interface in
dbus API). We also more correctly track the rules for unique ids so
that filter matching work for those too (previously filters only
worked if you sent to the well known bus name, not the unique name).
In terms of implementation, things have been simplified to *only* use
Filter rules rather than tracking policies and filters separately.
Also we track all the previously known owned names for a unique id
rather than just the highest policy for it. We can then look up all
filters for it, instead of a simplified policy only check.
In terms of the CLI everything is the same, except --filter=foo has
been renamed to --call=foo, to avoid the weird conflict with the
--filter (no =..) option. We also added a similar --broadcast to
filter received broadcasts.
Closes: #1730
Approved by: alexlarsson
This just keeps the fd alive until the FlatpakBwrap is freed, it
doesn't actually pass it on to the child.
We want to use this to keep a file lock held until the sandbox has
started where it takes over the lock.
Closes: #1730
Approved by: alexlarsson
Now that name.* matches the name itself we can simplify the default rule
from `--own=name --own-name=name.*` to just `--own-name=name.*`.
Closes: #1730
Approved by: alexlarsson
This means a rule like org.the.foo.* now also matches org.the.foo itself, and also
any sub-matches longer than one element, so for instance it now also matches
org.the.foo.bar.gazonk in addition to org.the.foo.bar which was already accepted
before.
The reason for this is that we want to be able to use the work in
https://bugs.freedesktop.org/show_bug.cgi?id=101902
to do filter in the actual dbus daemon instead of having to use a proxy, and
we need the two to behave the same way.
This is a slight widening of the access which could technically grant
apps access to something that they did not have before. However, given
the current state of sandboxing and what is currently in use this does
not seem too problematic.
Closes: #1730
Approved by: alexlarsson
This allows one extension point to match multiple versions of an extension.
In particular, this is useful for OpenGL so that we can match the version matching the current
runtime, as well as the "magic" 1.4 version for nvidia.
Closes: #1722
Approved by: alexlarsson
We forgot to include the sources. Also, we rename the valgrind header
to -private to avoid gtk-doc blowing its mind trying to parse it.
Closes: #1729
Approved by: alexlarsson
This gives access to AF_BLUETOOTH sockets in the seccomp rules. You additionally
need to give network access for the sockets to really work, because the
kernel doesn't (yet) namespace bluetooth sockets.
Closes: #1721
Approved by: alexlarsson
This also adds a call to this from flatpak build, although it is
not (yet) strictly necessary as all the flags it sets so far
are always set when building. This may change in the future though.
Closes: #1721
Approved by: alexlarsson
As per https://bugs.kde.org/show_bug.cgi?id=361770, this is not supported
by valgrind. We just don't seal the fds when debugging, this won't
affect anything at runtime in the normal case.
Closes: #1720
Approved by: alexlarsson
This moves all the files from lib into common, and it also adds all the libflatpak
sources into libflatpak-common, making libflatpak just a wrapper around the common
helper library.
This move allows the CLI to use all the code from libflatpak. We were already doing
this with a few things like flatpak-error*.[ch], and we want to do it even more
when sharing FlatpakTransaction. This also allows use to slowly move
the CLI to using the libflatpak apis for some things.
Closes: #1706
Approved by: alexlarsson
Add FLATPAK_UPDATE_FLAGS_NO_PRUNE and flatpak_installation_uninstall_full()
to the documentation, along with a couple of small fixes.
https://github.com/flatpak/flatpak/issues/1703Closes: #1705
Approved by: pwithnall
Sometimes, it can be interesting to allow specifying that we don't want to
run a prune operation right after uninstalling a flatpak, so let's add this
new method and a new FlatpakUninstallFlags type so that we can express that.
https://github.com/flatpak/flatpak/issues/1703Closes: #1704
Approved by: alexlarsson
Add a new FLATPAK_UPDATE_FLAGS_NO_PRUNE so that we can specify from clients
when we don't want to perform a prune right after updating a flatpak, even
if no FLATPAK_UPDATE_FLAGS_NO_PULL flag has been set.
https://github.com/flatpak/flatpak/issues/1703Closes: #1704
Approved by: alexlarsson
The current condition being checked to decide when to prune after updating
a flatpak from the public API is probably not the best one, since NO_DEPLOY
doesn't imply that prunable objects will be available, as that's something
that depends on whether a pull operation is performed, not a deployment.
So, change that condition so that we now always prune after updating unless
a NO_PULL flag has been explicitly set, which means that no prunable objects
would be available and so it's safe to ignore that step.
https://github.com/flatpak/flatpak/issues/1703Closes: #1704
Approved by: alexlarsson
Since the remote metadata can come from either the summary file or the
ostree-metadata ref, and the latter is available offline, there's no
reason to require the summary file when fetching metadata. This commit
changes flatpak_installation_fetch_remote_metadata_sync() and
flatpak_installation_fetch_remote_size_sync() to treat summary fetch
errors as non-fatal. Treating them as fatal is currently preventing
GNOME Software from doing LAN app updates.
GNOME Software should ideally be using metadata from the commits
themselves, but that change will have to wait for the fix for
https://github.com/flatpak/flatpak/issues/1592, I think.
Closes: #1701
Approved by: alexlarsson
This way everything works with /var/tmp on tmpfs or other non-xattr system
by default. The reason we used to use bare-user for the child repo is that bare-user-only
can't represent all possible ostree repos. For instance a file non-canonical permissions
such as "readable by user but not other/group" cannot be stored. Reading back such a file
when commiting to the real repo would give you a repo-corrupt error.
However, its been a long time since we made flatpak always generate canonical permissions
for all exports, so at this point I think its safe to switch this over by default.
This also fixes https://github.com/flatpak/flatpak/issues/1622Closes: #1686
Approved by: alexlarsson
Currently if you try to do an offline app install from a USB drive and
the app requires a runtime that's not already installed (or a different
version is installed), the install operation will fail, even if the
needed runtime is available on the USB drive.
The commit ensures that you can successfully find the dependencies
available from peer sources by making flatpak_dir_remote_has_ref() use
flatpak_dir_get_remote_state_optional(), which treats a summary fetch
error as non-fatal. Due to how flatpak_remote_state_lookup_ref() is
written, the summary is still required if there's not a collection ID
set on the remote.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1583Closes: #1673
Approved by: pwithnall
Currently when you try to do an offline app install from a USB drive,
the install succeeds but without installing any of the related refs,
even if they're available on the USB. This means you end up with a
broken install that's missing locale extensions, content, etc. depending
on what the related refs provide.
The related ref information is already gleaned from the xa.cache data
which is available offline via ostree-metadata refs that should be
provided by peer sources (and available in summary files as well). In
the near future this will be changed so that we use commit metadata
instead of xa.cache (see https://github.com/flatpak/flatpak/issues/1592)
but for now it at least allows offline installs to work. So the only
remaining step is to remove a dependency on the remote summary when
checking for the related ref in the remote in
flatpak_dir_find_remote_related(). This is accomplished by reworking
flatpak_remote_state_lookup_ref() so that it falls back to using the
xa.cache data when the summary isn't available. One effect of this is
that we no longer necessarily have the checksum for the ref, since
checksums aren't present in xa.cache data. As far as I can tell, none of
the consumers of this API have a hard dependency on the checksum
information (I checked GNOME Software too).
This is a partial fix for https://github.com/flatpak/flatpak/issues/1583Closes: #1673
Approved by: pwithnall
