This makes it a lot easier to give guidance on using `flatpak run -d` or
`flatpak-coredumpctl`, because there's an easy way to install the
relevant refs.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
As discussed in #4848, this disables fuzzy matching when the string
given has a period in it. So for example "flatpak install org.mozilla"
would not offer "org.mozilla.firefox" even though the string given is a
substring of the app ID. This is desirable because it helps ensure fuzzy
matching is only used when the user intended to use it.
As with the previous commit that fixed#4829, this does technically
break backwards compatibility, but only in an interface intended for
interactive use by a human, not an interface that's used
programmatically, so it seems okay.
This reintroduces the special case that existed in Flatpak 1.12.3, but
under a different name, so that it will be backwards-compatible. With
this change, flatpak-builder will be able to resolve CVE-2022-21682 by
using --filesystem=host:reset.
We want to implement this as a suffix rather than as a new keyword,
because unknown suffixes are ignored with a warning, rather than causing
a fatal error. This means that the new version of flatpak-builder will
be able to run against older versions of flatpak: it will still be
vulnerable to CVE-2022-21682 in that situation, but at least it will run.
Co-authored-by: Alexander Larsson <alexl@redhat.com>
There are two reasonable interpretations for --nofilesystem=home:
either it revokes a previous --filesystem=home (as in Flatpak 1.12.2 and
older versions), or it completely forbids access to the home directory
(as in Flatpak 1.12.3). Clarify the man pages to indicate that it only
revokes a previous --filesystem=home. This will hopefully reduce
mismatches between the design and what users expect to happen, as
in flatpak#4654.
A subsequent commit will introduce a way to get the Flatpak 1.12.3
behaviour in a way that is more backwards-compatible with Flatpak 1.12.2
and older versions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The new behaviour caused regressions in some situations that previously
worked, and will be reverted.
This reverts commit 4d11f77aa7.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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)
