The OCI support relies on downloading a json index and converting it
to a ostree-style summary, which we the use in all sorts of operations
in the client code. Currently this happens in the user code, which means
that it will fail (due to permissions) in the system installation case.
We could do the conversion as the user, but when eventually installing
something the system-helper will anyway do this download and
conversion, so that would only double the work and risk things going out
of sync. Also, the OCI index is not gpg signed, so we can't realy on
downloads done as the user.
So, the solution done here is to add a GenerateOciSummary
system-helper call which we use instead of directly generating the
oci summary.
This fixes https://github.com/flatpak/flatpak/issues/2350Closes: #2363
Approved by: matthiasclasen
Make it clear that the command can be used a few different ways, and the
option used determines the needed positional arguments.
Closes: #2361
Approved by: matthiasclasen
Previously, downloaded files were being saved with 0600 permissions,
which prevented OCI icons downloaded by the system helper at appstream
creation time from being read by users.
Closes: #2362
Approved by: matthiasclasen
Currently by an accident of history when the system-helper is asked to
deploy updates to the repo metadata (stored on the ref
"ostree-metadata") it uses the polkit action
org.freedesktop.Flatpak.runtime-install since the ref doesn't start with
"app/" and is therefore assumed to be a runtime. This of course doesn't
make much sense, so this commit redirects such invocations of the
"Deploy" method to the "modify-repo" action, which is a bit of a
catch-all of things the system-helper should be allowed to do. It
doesn't seem necessary to split this out into its own action, since
sysadmins probably don't need the ability to break Flatpak's expected
functionality by disabling it. See the PR for more discussion.
Fixes https://github.com/flatpak/flatpak/issues/2328Closes: #2351
Approved by: matthiasclasen
Originally the modify-repo action was only used by the RemoveLocalRef
method, which has "remote" and "ref" parameters, but now other methods
use it which don't have such parameters. So this commit modifies
flatpak_authorize_method_handler() so that we're not trying to pass
information along to polkit that we might not have, and modifies the
message shown by polkit to be more accurate.
Closes: #2351
Approved by: matthiasclasen
This requires some new mechanisms: now we're skipping individual tests,
not just whole test scripts.
There are two main reasons why autobuilder environments might not be
able to run these tests successfully, both of which apply in Debian.
Tests that rely on bwrap typically can't pass in builds that take place
in a chroot, because bwrap's use of pivot_root() assumes that the root
directory is a mount point, but a chroot will typically have an unpacked
directory somewhere below the mount point as its root.
Some autobuilder environments are also sufficiently restricted that they
can't create new user namespaces at all, as a way to harden the
autobuilder host.
As a result, Debian autobuilders can't run the majority of the Flatpak
tests. We would like to be able to continue to run the subset that don't
need bwrap, to have the best test coverage we can. For the rest we have
to rely on installed-tests (which I've wired up to Debian's autopkgtest)
rather than using build-time tests.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2339
Approved by: matthiasclasen
This is not a functional change: the default return value is equivalent
to polkit.Result.NOT_HANDLED. However, this makes the behaviour more
obvious.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2354
Approved by: matthiasclasen
This makes it clearer that we are not assuming that the test is running
on an x86_64.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2353
Approved by: matthiasclasen
Firstly this changes the "download-if" and "enable-if" properties
to accept a `;` separated list of multiple conditions.
Secondly it adds `on-xdg-desktop-*` which will check against
the XDG_CURRENT_DESKTOP env var (case-insensitively).
This is done entirely for the Qt GNOME Platform so it can do this:
```
"org.kde.PlatformTheme.QGnomePlugin" : {
"download-if": "on-xdg-desktop-GNOME;on-xdg-desktop-GNOME-classic"
}
```
Closes: #1436
Approved by: matthiasclasen
This adds support for fuzzy matching ref names (AKA "typo helper") to
the uninstall command to mirror what the install command has. In short,
this means you can do "flatpak uninstall gedit" instead of "flatpak
uninstall org.gnome.gedit". Flatpak will prompt you to choose between
similarly named installed refs, and will only make the choice for you if
--assumeyes was used and there's only one match.
Note that this commit does have the side effect that if there are
multiple matching refs with the same ID (e.g. with different branches or
in different installations) you are prompted to choose between them.
Previously you were shown an error message.
Closes: #2330
Approved by: matthiasclasen
This also includes the NEWS posts from 1.0.3 to 1.0.6 first
to avoid duplication and since it makes sense for users. After
all, 1.1 is released after 1.0.6 was released.
When installing a flatpak with extra-data we execute the apply_extra
script from the flatpak to extract the extra data files we
created. This script runs with very little filesystem acces, but it
does have write permissions to the location that will eventually be
/app/extra in the finished flatpak. This is especially problematic for
the systemwide install case, because the script is then run as root,
so it could potentially create a setuid file there.
Such a file would not be usable inside the sandbox (because setuid is
disabled in the sandbox), but it could potentially be a problem if the
user could be tricked into running the file directly on the host. This
is the same behaviour as e.g. rpm or deb which both can install setuid
files, but we want to guarantee that flatpak is better than that.
The fix is to run the script with all capabilities dropped (bwrap
--cap-drop ALL) which removes a bunch of possible attack vectors (for
instance setting file capabilities). However, even without
capabilities, it is possible for a user to make any file setuid to the
same user, so we also need to canonicalize the permissions of all
files generated by running the script.
Additionally, while running the script we set the toplevel directory
only be accessible to the user, meaning we will not temporarily leak
any potential setuid files to other users.
Note, this commit actually goes furthen than that and completely
canonicalizes all the file permissions to be the same as those
otherwise used by flatpak. For example we fix up cases where the
script creates files writable or unreadable by non-root users.
Closes: #2323
Approved by: alexlarsson
If you have a pre-existing remote configured its exact definition
might differ from the one specified in a flatpakrepo file and yet
be the same.
For example, i have:
$ flatpak --user remotes -d
Name Title URL Collection ID Priority Options
flathub Flathub https://dl.flathub.org/repo/ org.flathub.Stable 1
Yet when i install a flatpakref:
$ flatpak --user install http://flathub.org/repo/appstream/org.gnome.gedit.flatpakref
The application org.gnome.gedit depends on runtimes from:
https://dl.flathub.org/repo/
Configure this as new remote 'flathub-1' [y/n]:
Because the flathub flatpakrepo does not yet have the collection id specified.
So, we need to be more lenient when matching the pre-configured remotes.
Closes: #2324
Approved by: alexlarsson
This commit adds a key called DeployCollectionID to the flatpakref and
flatpakrepo file formats, which is intended to replace the CollectionID
key (which is still supported but deprecated). The reason for the change
is the same as for the metadata key change from xa.collection-id to
ostree.deploy-collection-id, which is that old versions of Flatpak
(roughly 0.9.8 through 1.0.1 depending on compile time options) hit
various bugs when collection IDs are in use. Flathub will soon enable
the metadata key to deploy collection IDs, and this change means Flathub
can also deploy the collection ID in flatpakref and flatpakrepo files
without affecting old clients.
Adding DeployCollectionID to the flatpakref and flatpakrepo files will
mean the flathub remote can be automatically configured with a
collection ID without depending on the metadata key to do that.
Closes: #2329
Approved by: alexlarsson
When --delete-data is passed when uninstalling an app,
remove its app data directory in ~/.var/app/. When
--delete-data is used without a ref, remove all 'unowned'
app data directories.
Closes: #2314
Approved by: matthiasclasen
This is a debugging tool so there's no need for a strict sandbox. I
want to be able to extract backtraces from gdb using 'set logging on'
and it's not currently possible without using
--extra-flatpak-args="--filesystem=home".
Closes: #2313
Approved by: matthiasclasen
We want to avoid unnecessary confusion and complications,
so we rule out IDs that are problematic because they will
clash with the default installations.
At the same time, make the error messages for parsing
custom installations more informative.
Make synopses more concise in various place, improve
consistency of formatting, and fix some small mistakes
and oversights.
Closes: #2307
Approved by: matthiasclasen
This is currently only used in the ‘search’ built-in command, but will
need to be used in upcoming parental controls filtering changes in
Endless OS (which will go upstream eventually) too.
This introduces no functional changes.
The CFLAGS/LIBADD changes are necessary because of the new
AppStream #includes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2296
Approved by: matthiasclasen
And hence provide at least a little bit of hope that this doesn’t become
permanent technical debt.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2296
Approved by: matthiasclasen
We generate various configuration files for each sandbox instance,
and expose them to the sandbox using flatpak_bwrap_add_args_data,
which in the end passed --bind-data to bwrap. These files are not
sensitive or shared, but it still doesn't really make sense for
the sandbox to allow them to be modified, so lets switch them
to --ro-bind-data.
This affects these files in the sandbox:
$HOME/.var/app/$APPID/config/user-dirs.dirs
/etc/group
/etc/ld.so.conf
/etc/passwd
/etc/pkcs11/modules/p11-kit-trust.module
/etc/pkcs11/pkcs11.conf
/etc/timezone
/run/flatpak/ld.so.conf.d/*.conf
/run/user/$UID/pulse/config
/run/user/$UID/Xauthority
