Otherwise, anytime we fail in ostree_repo_write_metadata() will cause
an invalid free to happen, and flatpak to crash.
(cherry picked from commit d0b5b51076)
At the moment, flatpak applications are only given FamilyLocal family
xauth cookies from the Xauthority file. This is so, the sandboxed
application doesn't inadvertently get access to displays on other
computers.
But FamilyLocal isn't the only xauth family that's local. FamilyWild
entries can be local as well.
Furthermore, FamilyWild entries are preferable to FamilyLocal entries
when found, because they don't break if the system hostname is changed.
This commit makes FamilyWild xauth entries get propagated in the same
way as their FamilyLocal counterparts.
(cherry picked from commit a82708cb10)
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)
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 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)
Apps may rely on /var/tmp not being in ram, for instance when
downloading large files. See for instance:
http://0pointer.net/blog/projects/tmp.html
We make /var/tmp point to ~/.var/app/cache/tmp so that each app get
its own instane, and so that its cleared whe removing xdg-cache-dir
for the app.
The main loop that is initiated while the extra data is being downloaded
needs a different context to be the thread-default one, otherwise the
operations just hang when running from a different thread.
If the bundle contains an origin link we can now install related
things from it, such as locale data.
You can also build the bundle with --runtime-repo=URL, where the url
points to a flatpakrepo file for a repo with runtimes. This works
similar to the RuntimeRepo= feature in flatpakref files.
This will be useful for testing purposes, so that we can provide
our own versions of the configuration files normally under
/etc/flatpak/installations.d.
I set these as separate bits by mistake when there's no good reason for
them to be like that, as they are not flags that are meant to be combined,
but a list of exclusive values.
Alexander Larsson