Previously, --filesystem=/run would prevent apps from starting by
breaking our ability to set up /run/flatpak and /run/host. Now it is
ignored, with a diagnostic message, resolving #5205 and #5207.
Similarly, --filesystem=/symlink-to-root (or --filesystem=host) would
have prevented apps from starting if a symlink like
`/symlink-to-root -> /` or `/symlink-to-root -> .` exists, and refusing
to export the target of that symlink avoids that failure mode,
resolving #1357.
Resolves: https://github.com/flatpak/flatpak/issues/1357
Resolves: https://github.com/flatpak/flatpak/issues/5205
Resolves: https://github.com/flatpak/flatpak/issues/5207
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f325564c9a)
If $HOME is below a reserved path (for example `/usr/home/thompson`
for Unix traditionalists) or otherwise cannot be shared, or is a
symbolic link to somewhere that cannot be shared, then we will end
up running the app with $HOME not existing. This is unexpected, so
we should make more noise about it.
There are two situations here, both of which get a warning: if we have
--filesystem=home or --filesystem=host then we are trying to share the
real $HOME with the application, and if we do not, then we are trying
to create a directory at the location of the real $HOME and replicate
the chain of symlinks (if any) leading from $HOME to that location.
Unlike the previous commit, this is not expected to happen during unit
testing, so we do not use a g_warning() for this.
Diagnoses: https://github.com/flatpak/flatpak/issues/5035
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit b85d30365e)
If the user gives us a override or command-line argument that we cannot
obey, like --filesystem=/usr/share/whatever or
--filesystem=/run/flatpak/whatever, then it's confusing that we silently
ignore it. We should give them an opportunity to see that their override
was ineffective.
However, there are a few situations where we still want to keep quiet.
If there is a --filesystem argument for something that simply doesn't
exist, we don't diagnose the failure to share it: that avoids creating
unnecessary noise for apps that opportunistically share locations that
might or might not exist, like the way the Steam app on Flathub asks
for access to $XDG_RUNTIME_DIR/app/com.discordapp.Discord.
Similarly, if we have been asked for --filesystem=host, the root
directory is very likely to contain symlinks into a reserved path, like
/lib -> usr/lib. We don't need a user-visible warning for that.
We actually use the equivalent of g_message() rather than g_warning(),
to avoid this being fatal during unit testing (in particular when we
do a `flatpak info` on an app that has never been run, which will
be unable to share its `.var/app` subdirectory). `app/flatpak-main.c`
currently displays them as equivalent to each other anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit dc7b1e873b)
This test has consistently failed for months as it takes too long.
While it should be looked into its not helpful to show CI as always failing either.
(cherry picked from commit 8daa975ab3)
Same as the previous commit, but for anything that runs in the
background.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ea584acf20)
This makes us consistent with the default behaviour of GLib, and
its behaviour with G_MESSAGES_DEBUG=all. g_debug() and g_info() are
the two lowest priority levels, and GLib normally silences them by
default.
At the moment, Flatpak uses G_LOG_LEVEL_DEBUG in the flatpak2 domain
as its lowest-priority log level (only shown with flatpak -v -v), and
G_LOG_LEVEL_DEBUG in the flatpak domain as its second-lowest
(shown with flatpak -v or higher). I want to move towards using
G_LOG_LEVEL_INFO for flatpak -v messages, and G_LOG_LEVEL_DEBUG for
flapak -v -v, so that we don't need a second log domain: this is a
policy I've used successfully in Flatpak-derived Steam Runtime code.
This change does not fully implement that policy, but gives us a
migration path towards it, by allowing us to start using g_info() for
flatpak -v messages.
Helps: https://github.com/flatpak/flatpak/issues/5001
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ac4e322629)
This variable contains paths to load GIO modules from. For the most
part, they refer to paths outside of the sandbox or if they happen
to be in the sandbox, would contain modules that are incompatible with
the sandbox runtime (ie. different libc).
While I've not found programs that would crash outright, it may cause
unexpected behaviors (eg. Apostrophe not being able to render math in
preview panel).
This variable is set by NixOS for its dependency boxing.
(cherry picked from commit df0b9d98b5)
This variable is typically used to configure the use of a custom
set of XKB definitions. In those cases, it's mostly meant for the
X11 server or Wayland compositor. NixOS is known to employ this
variable for their custom XKB layout implementation.
When the path it points to is unreachable (due to the sandbox),
most GTK+/Qt applications will crash on Wayland.
Unsetting this does not seem to negatively impact the use of custom
XKB layouts with Flatpak applications.
(cherry picked from commit 751ff11d3a)
If this environment variable is set on the host, it's going to mess up
authentication in the sandbox. For example, if the host has:
KRB5CCNAME=KCM:
then the sandboxed process will try to use the host KCM socket, which is
not available in the sandboxed environment, rather than the gssproxy
socket that we want it to use. We need to unset it to ensure that
whatever configuration we ship in the runtime gets used instead. We have
switched the GNOME runtime to use an empty krb5.conf and it works as
long as we don't break it with this environment variable meant for the
host.
(cherry picked from commit 1c32317841)
Previously in a0505f52d9
the profile script was modified to preserve XDG_DATA_DIRS.
This had the side-effect of making the script not idempotent,
adding duplicate entries for every installation every time it's sourced.
On my current system that results in this value:
/home/mkhl/.local/share/flatpak/exports/share /var/lib/flatpak/exports/share /home/mkhl/.local/share/flatpak/exports/share /var/lib/flatpak/exports/share /usr/local/share /usr/share
which in turn has the side-effect of the GNOME search settings showing two entries
for every application installed via flatpak.
This change makes the script check that an entry is new before adding it.
It also uses `set -p` (short for `--prepend`) to add them.
N.B.
`set -p VAR val` is equivalent to `set VAR val $VAR`
`$var[-1..1]` reverses the order of elements
so after iterating the first element of `$installations`
becomes the first element of `$XDG_DATA_DIRS`
(cherry picked from commit 16707a1937)
Exporting to an existing repo on a Samba filesystem failed with EACCES
when libglnx called renameat() to replace the old summary.idx file.
error: renameat: Permission denied
This occurred even when the user had appropriate permissions to the file
and its ancestor directories. The problem was that flatpak had mapped the
old file into memory for reading, and still held a reference to that mapping
when attempting to replace the underlying file. Apparently this works on some
filesystems, but not on cifs.
We therefore release the memory mapping before replacing the underlying file.
Fixes#5257
Co-authored-by: Patrick <tingping@tingping.se>
(cherry picked from commit 01910ad12f)
gitlab.gnome.org is currently down, so use a mirror.
The specific commit we are using has not changed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit bdfebb44da)
gitlab.gnome.org is currently down, so use a mirror.
The specific commit we are using has not changed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7cb9eb3ebc)
The project was moved to a new namespace a while ago, and is now using
the main branch rather than master.
The specific commit we are using has not changed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f9a7d12014)
This should make it a bit clearer when `rm -rf` is being used in the
debug logs.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit 6c7eb34dd6)
Before 1.8.0 (2016), gpgme used to have two different thread-safe builds,
one for use with POSIX-style pthread and one for use with GNU Portable
Threads (libpth), plus a non-thread-safe version. Since 1.8.0, this
complexity has gone away and there is only libgpgme, which is thread-safe.
In practice this meant that on modern distros since 2016, we would always
fail to detect gpgme via pkg-config and fall back to calling gpgme-config.
Library-specific -config scripts are generally considered problematic
for multiarch, multilib and cross-compiling, and the gpgme-config script
recently disappeared from GPGME's Debian packaging
(see https://bugs.debian.org/1022348 and https://bugs.debian.org/1023601),
so it's better if we can prefer to use pkg-config.
If gpgme >= 1.8.0 is not found, fall back to gpgme-pthread >= 1.1.8,
either discovered via pkg-config or via gpgme-config.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9b87e4c0d4)
When filesystem=host access is provided, some root folders are hidden, including /boot.
The bootloader specification now recommends mounting the system EFI filesystem in /efi
(currently visible) instead of /boot/efi (currently hidden). This hides /efi for the same
reasons /boot is already hidden.
(cherry picked from commit 397c97de9f)
This supplements clearing TMPDIR env variable which is only one among variables used for storing temporary files. Any of those leaking from host may confuse flatpak apps which try to save temporary files under non-existing directory in sandbox.
See https://github.com/flathub/com.logseq.Logseq/issues/29 for real world example.
(cherry picked from commit d8695f3071)
When built for i386 with Autotools, this would have detected the format
string issue fixed in #5148.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit de4de4dc44)
revokefs already gets the correct include directory from the AM_CPPFLAGS.
This would also break the build with -Werror=missing-include-dirs.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 190bad06d2)
This already happens for installs due to the cleanup path in
`flatpak_dir_deploy_install()`, but it doesn’t happen for other calls to
`flatpak_dir_deploy()`. Notably, during updates of already installed
apps.
Specifically, this means that if an app update is cancelled due to being
blocked by a parental controls policy, the temp deploy dir for that app
(such as
`~/.local/share/flatpak/app/com.corp.App/x86_64/stable/.somehex-XXXXXX`)
will be leaked. It will never be automatically cleaned up, as it’s not
in `/var/tmp` either.
Fix that by using `glnx_mkdtempat()` to create a scoped temporary
directory.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit ce1829a703)
This fixes the build on ILP32 architectures such as i386 with the Meson
build system. The Autotools build system accidentally didn't build
revokefs with -Werror=format, because it sets the target-specific CFLAGS
for revokefs but does not include the $(AM_CFLAGS) in them.
Fixes: aeecbb7d "revokefs: Split out the writing part from the fuse implementation"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 959910f933)
The profile script previously nuked `XDG_DATA_DIRS` and then
“helpfully” re-populated it with FHS paths. This was especially
bad for systems like NixOS, which do not have `/usr`
and rely on `XDG_DATA_DIRS` heavily.
Quoting from https://fishshell.com/docs/current/cmds/set.html
> If a variable is set to zero elements, it will become a list with zero elements.
And indeed, that is what the `set -x --path XDG_DATA_DIRS` command does.
We need to list the value explicitly, if we want to preserve it
while setting variable options.
(cherry picked from commit a0505f52d9)
Exiting the process with a custom exit status (1) after systemctl stop
(SIGTERM) makes systemd treat the flatpak-session-helper service as if
it had failed.
Signed-off-by: Alberto Garcia <berto@igalia.com>
(cherry picked from commit c1f0370958)
