So far, the installation of external apps can only be cancelled
before flatpak starts downloading the extra data, as there's no
cancellable being passed to g_input_stream_read_async().
This fixes that problem, making it possible to cancel installs
from GNOME Software regardless of the installation stage.
(cherry picked from commit 86bf88d89f)
Otherwise, clients such as GNOME Software won't be able to report
any progress once the flatpak application has been downloaded and
we enter the stage to download the extra data.
(cherry picked from commit 2e1740297c)
Otherwise, all the progress reporting for the extra data being downloaded
won't work, as the main context used by OstreeAsyncProgress will not be
the same than the one from the nested main loop used to download this.
(cherry picked from commit ca952b0f21)
It turns out that it is impossible for to get ptrace capabilities
for child user namespaces in the current kernel if the user
namespace is created as root, which is what happens when bwrap
is setuid root (see https://github.com/flatpak/flatpak/issues/557
for details).
This is very problematic, as ptrace rights controls access to
/proc/$pid/root which is what we base the detection of peer
app id and rights on for portals.
For now, we disable user namespaces (except for the case of
unprivileged user namespaces, where it is necessary and works).
(cherry picked from commit 521e7e6a37)
If we have network access, then nvidia talks to the xserver
and for some reason it then also needs /dev/nvidia-modeset.
So, lets add that to the dri device list.
(cherry picked from commit 763a686d87)
This is supposed to list all the currently loaded "non-standard" gl drivers.
If FLATPAK_GL_DRIVERS is set, then that is used, otherwise it looks
for an nvidia driver and if so, uses that, and always adding "default"
at the end which is meant to resolve to a stable mesa fallback build, as
well as "host" which can be used if you have a host-side driver
as an unmaintained extension.
(cherry picked from commit d4d15c7211)
If directory is "foo" and the extension id ends with ".ext" and
subdirectory-suffix is "sub" then the extension point will
be "/usr/foo/ext/sub" rather than just "/usr/foo/ext".
This is very useful when the extension point naming scheme is
"reversed". For instance, this happens for the /usr/share/themes directory.
An extension point for a gtk3 theme would be in /usr/share/themes/$NAME/gtk-3.0,
which could be achived by using subdirectory-suffix=gtk-3.0.
(cherry picked from commit 5e1d456b8b)
If your extension points set this, then each extension will have
the corresponding subdirectory added to LD_LIBRARY_PATH.
We also support a priority property in the ExtensionOf group
in the extensions themselves to set the search order.
(cherry picked from commit a3da0b3da8)
If we sort, or subset the extensions we use, then we can't just
set need_tmpfs on the first one, instead do the checking
for the first one when we're applying the extensions.
(cherry picked from commit 7f8ad5b3a1)
In extract_extra_data(), flatpak currently returns TRUE whenever
flatpak_repo_get_extra_data_sources() returns NULL, which is correct
most of the times since that's usually caused by the extra-data
finish-args argument not being present.
However, that operation relies on OSTree's ostree_repo_load_variant()
too, which could fail for unrelated reasons. And in those cases flatpak
would still keep returning TRUE here even in cases where the extra-data
sources could be there, but an error happened while retrieving it.
This seems to be a bug leading to unlikely -yet possible- situations,
where the user would end up with an "external app" like Spotify reported
to be succesfully installed but without the files/extra directory, which
is useless.
(cherry picked from commit 1d7357616b)
Just because stdout/stderr happen to be going to a terminal doesn't
necessarily mean that we want the command launched by HostCommand
to take ownership of the terminal - in the case where 'flatpak run'
is launched from a terminal, stderr will typically be left pointing
to the terminal for any command. In that case the terminal already
has a controlling process, and TIOCSCTTY will fail; avoid scary
messages by making the failure only a g_debug()
(cherry picked from commit 5f12c9e328)
It turned out that some sources where bind-mounted read-write
which should have been read-only:
* Extensions
* Fonts
* resolv.conf
* localtime
* machine-id
Many of these are not generally writable by the user, but
some are, which is pretty bad. For instance if the an
app is user-installed it will be able to write to its
locale data.
We fix this by using --ro-bind where needed.
(cherry picked from commit bc5ea57226)
We make /etc just a symlink to /usr/etc when we're building a runtime
and /etc is supposed to be writable. Otherwise the bind-mount we
normally have there don't allow use to replace existing files in /etc.
(cherry picked from commit ab446ebac5)
The socket directory then ended up in $HOME which was read-only, so
we couldn't create the socket. We solve this by putting the sockets
in a subdirectory and always making this directory writable in the
proxy.
(cherry picked from commit 0bea92bd73)
Before this commit
$ flatpak install --arch someArch --from some.flatpakref
Would completely ignore the arch argument and only install for the
default flatpak architecture. Since flatpakref files don't include
an arch field, there's no reason we can't attempt to install the
arch specified on the command line.
(cherry picked from commit ee83b5a70d)
If EXTERNAL_INSTALL_DIR wasn't defined (which is likely, since nothing
in the build system does), then we would tell the system helper
to search /exports/share, which is not Flatpak's territory
(but is a semi-commonly-used path for site-specific NFS shares,
which might have contents that are inappropriate to search here).
Installations that do define an external installation directory
(Endless OS?) can easily override the Environment to include it
by placing a drop-in in
/etc/systemd/user/flatpak-system-helper.service.d/external.conf
or similar.
(cherry picked from commit 1d6834db4d)
If the homedir is on a symlink (say /home -> /var/home) but the homedir
is in /home, then we shouldn't create a directory in /home because
then the symlink creation will fail. Instead we move the homedir
creation to the end, where we will create it in the symlink if needed.
This should fix https://github.com/flatpak/flatpak/issues/493
(cherry picked from commit fa6f7228886e983a5c1ff64e1d9db8ea0014ec26)
If you are exposing a symlink, say /link (-> /target) and
also a child of it, say /link/child, then we run into dependency
issues. For instance, the /link symlink is created, pointing to /target,
but then we try to to create /link/child before the /target
bind mount is setup, which will fail.
We work around this by adding a level, and the dependency of a symlink
(/target in the above case) will always be handled first. This isn't
a perfect solution, but is likely to be good enough in practice.
(cherry picked from commit 5c4c4bbe56807ce94ef2eb0cc860b1cf488371f5)
During setup the new root is in /newroot, so absolute symlinks don't work.
We make them realtive so that we can resolve the symlinks during setup.
(cherry picked from commit b1dd1c3f7a865f39ef9f296e3a0f96304f96247c)
We need to use g_build_filename, g_build_path takes a separator
as the first arg, not a path!
(cherry picked from commit 896c483cac6897cef6202055ed127e37e09f5ab8)
This change fixes GCC compiler warnings where a cleanup function was
specified on an uninitialised pointer, which in the view of GCC could
result in an errornous free of uninitialised memory, if the functions
that initialise them do not return NULL.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
(cherry picked from commit 605c7ee87b)
