SHA1 hashes are considered weak these days. Some distributions have
static analysis tools to detect the use of such weak hashes, and they
get triggered by flatpak. While this particular use of SHA1 in flatpak
is likely not security sensitive, it's also easy to move to SHA256 to
avoid any debate.
Here, the SHA1 hash of a named remote's filter file is used to generate
the name of the directory where the refs from that remote are cached.
One can reasonably assume that the cache is frequently invalidated
because the list of refs on the remote changes all the time. Hence,
it's not big problem if it gets invalidated once more because of this
change.
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>
