Trying to run sandboxed GStreamer applications from within jhbuild, for
example, would make those applications fail to find their plugins.
$ LANG=C flatpak run org.gnome.Totem.Devel
** (totem:2): WARNING **: 19:32:06.406: Element 'gtkglsink' is missing, verify your installation
** (totem:2): WARNING **: 19:32:06.406: Element 'glsinkbin' is missing, verify your installation
Don't propagate those GStreamer environment variables to within the
sandbox to avoid that problem.
See https://gitlab.gnome.org/GNOME/totem/-/issues/504
which(1) is neither standardized by POSIX nor built-in to bash, and has
different implementations and behaviour on different distributions.
command -v is standardized by POSIX, but it won't return the path to an
executable if the same command is available as a shell builtin, so it
isn't necessarily suitable here either.
The Flatpak test suite uses bash scripts rather than POSIX shell scripts,
so we can safely make use of bash-specific options for builtins, and
in particular type -P, which has the semantics we want here: search PATH,
even if there is a shell builtin of the same name.
Signed-off-by: Simon McVittie <smcv@collabora.com>
which(1) is not standardized by POSIX, and has different implementations
and behaviour on different distributions. The behaviour and exit status
of command -v is standardized by POSIX, and in particular, checking its
exit status is an appropriate way to ask: if I called this command,
would it be found?
Signed-off-by: Simon McVittie <smcv@collabora.com>
In the unlikely event that one of these paths contains spaces or other
special characters, we don't want to field splitting to take place.
Signed-off-by: Simon McVittie <smcv@collabora.com>
which(1) is not standardized by POSIX, and has different implementations
and behaviour on different distributions. The behaviour and exit status
of command -v is standardized by POSIX.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Remove a redundant `PROP_0` member and add a type for the property IDs
so that the `switch` cases can be checked by `-Wswitch-enum`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This bundles up `{get,set}_no_interaction()` in a way which can be bound
or exposed to bindings.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This complements `flatpak_transaction_set_no_interaction()` and allows
calling code to see if a given transaction is interactive.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When generating flattened permissions (i.e. for --show-permissions or
for the /.flatpak-info file) we're currently flattening the permissions
i.e. don't show things that would only affect layering the permissions).
However, the code doesn't currently do this for the filesystem key, so
implement that. This means we only display the permissions that are
in effect, and don't display "negative" permissions like !host which
are not meaningful in this context.
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>
(cherry picked from commit 5709f1aaed)
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>
(cherry picked from commit 7bbeed2b87)
This caused regressions for some previously-working use cases. For
example, some Flatpak users previously used a global
`flatpak override --nofilesystem=home` or
`flatpak override --nofilesystem=host`, but expected that individual apps
would still be able to have finer-grained filesystem access granted by the
app manifest, such as Zoom's `--filesystem=~/Documents/Zoom:create`. With
the changes in 1.12.3, this no longer has the desired result, because
`--nofilesystem=home` was special-cased to disallow inheriting the
finer-grained `--filesystem`.
This reverts commit 445bddeee6.
This reverts the initial solution to CVE-2022-21682, which we intend to
resolve differently, by introducing a new feature in Flatpak and making
use of it in a new flatpak-builder version.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 917a7f5870)
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>
(cherry picked from commit dfe868d628)
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>
This caused regressions for some previously-working use cases. For
example, some Flatpak users previously used a global
`flatpak override --nofilesystem=home` or
`flatpak override --nofilesystem=host`, but expected that individual apps
would still be able to have finer-grained filesystem access granted by the
app manifest, such as Zoom's `--filesystem=~/Documents/Zoom:create`. With
the changes in 1.12.3, this no longer has the desired result, because
`--nofilesystem=home` was special-cased to disallow inheriting the
finer-grained `--filesystem`.
This reverts commit 445bddeee6.
This reverts the initial solution to CVE-2022-21682, which we intend to
resolve differently, by introducing a new feature in Flatpak and making
use of it in a new flatpak-builder version.
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>
We weren't distinguishing here between overrides that should have been
negated (xdg-documents) and overrides that should not have been negated
(everything else).
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 4e3d1d8b7b)
Normally, we want to save a process and get better signal handling
by replacing the `flatpak run` process with bubblewrap.
However, when we're doing profiling or measuring coverage, we want to
exit cleanly so that profiling data can be recorded, which is done in
an atexit() hook. In this situation, bypass the execve() optimization;
instead, start bubblewrap in the background, immediately wait for it,
and propagate its exit status.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We weren't distinguishing here between overrides that should have been
negated (xdg-documents) and overrides that should not have been negated
(everything else).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously --nofilesystem=host only removed specifically access to the
`host` permissions, and not necessarily other filesystems (like `home`
or `/some/path`). This isn't very useful to limit access because you
don't know what other filesystems the app may have access too.
We change this to mean that `--nofilesystem=host` removes *all* filesystem
access from the parent layer, and `--nofilesystem=home` removes all
file access to the homedir and paths inside it.
The available layers are, in order:
* app permissions
* overrides
* commandline args
This allows you to start from scratch with the filesystem permissions
in the overrides or the commandline. This is a small change in
behaviour, but not a lot of things use --nofilesystem, and the ones
that do probably expects this behaviour.
