If a runtime is installed explicitly rather than as a dependency, pin it
so it doesn't get automatically removed when unused runtimes are being
removed. We do this because the runtime might be installed for
development or other uses.
This commit also rearranges some code in the mask and pin commands, and
adds a unit test.
As discussed here [1], we want a way to mark runtimes to be kept even
when they are unused by any apps and we are removing such runtimes.
Currently this is a command that can be run manually; a subsequent
commit will pin runtimes automatically if they are installed
independently of any app.
A unit test is included.
[1] https://github.com/flatpak/flatpak/issues/2639#issuecomment-662311756
Historically we didn't accept them, but there's no real reason why not.
They're normalized to the form in which earlier Flatpak releases would
want to see them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently when searching for a remote to provide the runtime for an app,
we search remotes in priority order. This commit makes it so we search
the remote providing the app before others with the same priority, and
otherwise still search in priority order. This means for the common
case where every remote has the default priority of 1, the app's origin
will have the first chance to provide the runtime. This behavior seems
logical, but the impetus for this change was also to keep a unit test
passing in eos-updater[1] after a port to FlatpakTransaction.
Originally the eos-updater unit test was written to prioritize the
origin remote regardless of the priorities on any other remote, but
during code review it was decided to let higher priority remotes stay
above the app's origin.
In practice it's usually true that only one remote provides a runtime
and priorities aren't set at all, so this is an edge case that probably
doesn't come up much.
A unit test and documentation updates are included.
[1] eede0a8b9c/tests/test-update-install-flatpaks.c (L1919)
Previously, there were three different DTDs used. Let's switch to a single one.
We will go with 4.5, since it is latest version that does not have any backwards incompatible changes.
We only want the run dir to be overridable in unit tests because we
depend on it being /run/flatpak in flatpak-create-sideload-symlinks.sh,
so don't mention it in the flatpak man page.
Currently we only support links in /var/lib/flatpak/sideload-repos,
/run/flatpak/sideload-repos, etc. to be actual ostree repos, but this
commit makes it so you can also link to the root directory of a USB,
and Flatpak will check the subpaths "ostree/repo", ".ostree/repo", and
".ostree/repos.d" for compatibility with "flatpak create-usb". This will
allow the logic in the following commit to be much simpler, where we're
linking to hot-plugged drives in a script run by systemd.
Note that we still only allow actual repos in the other places where a
sideload path can be specified, such as the --sideload-repo CLI option.
Commits 32194f2d2 and b8d2196c2 made create-usb detect partially
installed commits and omit them except when --allow-partial is specified
(and in the case of extensions of related refs omit them
unconditionally). The reasoning was that if on the other computer using
the USB for an installation you need a different subpath of a commit
(such as a different language of a locale extension), the installation
will fail. But in most real world cases the users on both ends will
speak the same language so it will not often be an issue. Also, if you
are offline and have only your own language's subpaths for your locale
extensions, it makes sense to put them on the USB because you have no
way to get the full locale extension and the receiver probably wants the
same subpath as you.
The way "flatpak create-usb" is most often used in Endless is via
gnome-software which calls it under the hood. So while we could have it
pass --allow-partial that would not accomplish much; it doesn't solve
the problems above.
For the online case we may want to attempt to download the full locale
extensions before copying to the USB, but that is for a later commit.
Fixes https://github.com/flatpak/flatpak/issues/3491
The terms whitelist and blacklist are hurtful to some people, and per
our code of conduct Flatpak is an inclusive community. Replace them with
allowlist and blocklist which are also more clear. This terminology
change is being implemented more broadly in the software industry; see
e.g. https://go-review.googlesource.com/c/go/+/236857/
To avoid the complexities of passing (and chaining) OstreeAsyncProgress
objects around, we only create one just before calling to ostree.
The rest of flatpak only ever uses the new FlatpakProgress object.
Co-authored by: Philip Chimento <philip@endlessm.com>
Instead of having a global config option we scan a directory for
symlinks into the sideload repos. These come from
/var/lib/flatpak/sideload-repos and /run/flatpak/sideload-repos (for
default system installation).
This is much easier to update atomically, and the two different
options are useful for persistant (the first) or dynamic (the second)
usescase.
Fixes https://github.com/flatpak/flatpak/issues/3494
This is a new version of --deploy-collection-id that only applies
the collection id update for new (1.7.x+) version of flatpak clients.
This allows you to enable collection ids for sideload use but not
affect older clients where the p2p codepaths are not as tested.
New users who jump directly into this command might think this command is to init a project or application dictionary but it actually creates somehow a directory for *built* app to run inside.
plus, fix not working example
Sorry for such minor and boring commit.
These are subsets of the host keyword, which provide access to operating
system files but not to users' personal files.
In particular, the experimental support for namespace-based sandboxes
in the Steam Runtime[1] uses the graphics stack from the host system,
which requires access to the host /usr/libQUAL, /libQUAL (even if the
host OS has undergone the /usr merge, the canonical paths of ELF
interpreters start with /lib), /etc/ld.so.cache, and for some libraries
on Debian-based systems, /etc/alternatives. It will not be possible to
do similar things in Flatpak without either allowing full host
filesystem access (which exposes personal files, and in any case cannot
be done by the Steam app because it is incompatible with --persist=.),
or adding the ability to expose /usr and related directories without
including the rest of the host filesystem.
To the best of my knowledge, host-etc is not necessary for anything;
I've mainly provided it for symmetry, since it's the other significant
thing that we mount in /run/host and cannot get via --filesystem=/path.
Some notes on the security/privacy implications of the new keywords:
- Neither new keyword allows anything that was not already allowed
by "host".
- Neither new keyword can allow anything that was not already allowed
to the user outside the sandbox.
- "host-os" allows enumeration of the installed packages on the host
system, and often their version numbers too. A malicious app could
use this to look for exploitable security vulnerabilities on the
host system. An app could also use this for fingerprinting, although
this is not a regression, because the systemd/D-Bus machine ID,
MAC addresses, hostname, kernel boot UUID, DMI product ID and many
other unique or relatively unique properties are already available
inside the sandbox.
- "host-os" allows read access, and possibly write access (if the user
has it outside the sandbox, for example members of group 'staff' in
older Debian installations), to /usr/local.
- "host-etc" allows reading configuration files whose contents might
be considered sensitive, such as /etc/passwd.
[1] https://steamcommunity.com/app/221410/discussions/0/1638675549018366706/
Signed-off-by: Simon McVittie <smcv@collabora.com>
This new permission exposes the host /dev, which is normally not visible
even with --device=all, as it is not really a device node but rather
a bunch of shared memory blocks available on the host.
This access is needed by jack, as explained at:
https://github.com/flatpak/flatpak/issues/1509
Long term I think a better solution for pro audio (like pipewire) is
a better solution, but for now we should at least allow jack apps to work.
