This gives new support for the new XDG_STATE_HOME addition to XDG_BASE_DIRS
which allows applications to use this without breaking because they would
assume $HOME/.local/state which may be unavailable to the flatpak
This adds it as .local/state as to make --persist=.local/state the same behaviour
as in new flatpak. This in turn means that the transition should be seamless between
old and new flatpak.
This also has the benefit of working if the application doesn't follow XDG spec thanks
to --persist=.local/state.
This fixes https://github.com/flatpak/flatpak/issues/4477
[smcv: Don't call nonexistent g_get_user_state_dir(); fix a reference
to XDG_STATE_DIR]
g_key_file_get_boolean() only accepts lower case "true" and "false", so
correct some instances of "False" in key files. This makes no functional
difference as long as the error pointer isn't checked since
g_key_file_get_boolean() also returns false when it can't parse the
value as a boolean. But it still seems good to be correct, and someone
could interpret the existence of "IsRuntime=False" as implying that
"IsRuntime=True" will work, which it doesn't.
Similar to /tmp, applications might well use /dev/shm as an IPC
rendezvous between instances, which wouldn't have worked without
--device=shm until now.
Because /dev/shm has specific characteristics (in particular it's
meant to always be a tmpfs), we offload the actual storage into a
subdirectory of the real /dev/shm. Because /dev/shm is a shared
directory between all uids, we have to be extra-careful how we
do this, which is why the test coverage here is important.
This is done on an opt-in basis because of its extra complexity.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The pressure-vessel container tool in Steam will want to use this, to
replace /usr with a Steam Runtime container supplied by the Steam CDN,
instead of using the same Flatpak runtime that is used to run the Steam
client and non-containerized games.
If a custom /usr is used, the "official" Flatpak runtime is still the
one reflected in the metadata. It is also mounted at /run/parent,
with all its extensions, so that pressure-vessel has the option of using
its graphics drivers (by populating the custom /usr with symlinks into
/run/parent and/or /run/host).
When doing this, we need to put an empty directory on /app, because
the real /app expects to be run on top of the real runtime. It would
also be reasonable to substitute a custom replacement for /app, so
I've included support for that too.
Partially addresses #3797.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Use present tense consistently rather than gerunds for some headings in
"flatpak --help". Also tweak flatpak(1) to use similar wording but with
gerunds.
This follows up from GHSA-4ppf-fxf6-vxg2 to fix missing functionality
that I noticed while resolving that vulnerability, but is not required
for fixing the vulnerability.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with flatpak run --parent-expose-pids, this will only work if we have
a working, non-setuid bwrap. Systems where user namespace creation is
restricted and bwrap needs to be setuid (Debian 10, RHEL/CentOS 7,
Arch Linux linux-hardened kernel) will have degraded functionality.
This option is similar to --expose-pids, except that instead of making
the subsandbox use a nested pid namespace inside the parent's, it makes
the subsandbox share the parent's pid namespace as-is, so that process
IDs in the parent and the subsandbox are interchangeable. This will
be useful if the parent and the subsandbox communicate via protocols
that assume a global view of the process ID namespace, for example
passing process IDs across an AF_UNIX socket or in shared memory.
In particular, this will be useful for Steam's pressure-vessel container
tool: the IPC between the Steam client and the "game overlay" loaded into
Steam games uses process IDs, and becomes confused if they don't match up.
This weakens the security boundary between a subsandbox and the parent,
but that's OK in some cases, especially if the subsandbox is being used
as a way to get a different runtime /usr (flatpak-spawn --latest-version
or #4018) rather than as a security boundary.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is the environment needed to use flatpaks; a following commit will
hook this up to the systemd environment generator.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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/
