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.
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.
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).
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.
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.
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.
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.
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.
On unmonitored systems (if the session helper is not available), we
currently decide whether to create a symlink or a read-only bind mount
for /etc/localtime based on whether that's a symlink in the host or
not, but we don't check whether that symlink would be reachable in
the sandboxed environment, which might lead to bad situations.
This patch adds some extra checks relying on GFile's API to check
whether that symlink would be reachable before making the final
decision: if it's not, then do a bind mount despite of the file
being a symlink in the host.
https://github.com/flatpak/flatpak/issues/409
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.
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.
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.
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.
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.
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
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.
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>
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.
This will allow explicitly referring to the default installation
using the 'default' ID, as well as overriding its values via a
configuration file specifying that same ID.
Implemented the following functions along with the required internal APIs:
* flatpak_installation_get_id ()
* flatpak_installation_get_display_name ()
* flatpak_installation_get_priority ()
* flatpak_installation_get_storage_type ()
As per the discussion with GNOME Software maintainer Richard Hughes [1],
we need to support a few additional fields in the configuration files
for better integration with external clients. Thus, this commits adds
support for reading "DisplayName", "StorageType" and "Priority" values
from the configuration files, being all of them optional.
Note: priorities are currently used to sort the system installations
list statically stored in flatpak-dir.c (bigger number, bigger priority).
[1] https://mail.gnome.org/archives/gnome-software-list/2016-December/msg00000.html
This information will be used when querying system-wide installations,
so that we can refer to those pre-configured installations by the id
defined in the configuration files under /etc/flatpak/installations.d
This will return an array of FlatpakDir instances with all the system
installations configured via key files in an optional drop-in directory
under FLATPAK_CONFIGDIR/installations.d, plus the default one.
User and system installations is no longer a binary decision, so remove
this API to force explicit calls to either flatpak_dir_get_system_default()
or flatpak_dir_get_system_list() when dealing with system installations.
There will be a way to retrieve the list of all system installations,
not just the default one, so we rename this for backward compatibility.
Note that some (most?) of the places where we will be now using this
renamed function will likely have to migrate to using specific system
installations, but we don't have the necessary APIs yet so we do this
as an initial step to all the incremental changes that will come next.
These make no sense, we don't want to modify the runtime, and
we can't create parent directories there anyway which can cause
issues like https://github.com/flatpak/flatpak/pull/433
This was manully checked in some places, which can now be dropped, but
also the places that didn't check it before were buggy and needed
to check this, so better just fail early.
When no session helper is available (e.g. running flatpak run from a
socket-activated service unit), we need to be extra careful before
making these two files appear inside the sandbox. Otherwise, if they
are not reachable on the host system (or just symlinks to non-existent
targets), flatpak won't be able to create the sandbox, which will fail
due to a "No such file or directory error".
https://github.com/flatpak/flatpak/issues/409
We already kind of support this by exposing the parent directory,
so this isn't really less secure, and you should not be able to
access it unless your user is allowed to anyway.
This lets it work during early setup phase when the new root is at
/newroot. This allows us to create things in /var/run with
e.g. --filesystem=/var/run/foo.
If you're building a runtime and have a base runtime with expected
extensions, fail to build if the actually installed extension is
partial (i.e. if it has a subdir specified).
Fixes https://github.com/flatpak/flatpak/issues/390
If the app is explictitly given access to a subdirectory of
one of the xdg config/cache/data directories, with read-write
(or create) access, then also bind-mount that directory
into the corresponding .var/app/$APPID directory.
This allows apps that want it to keep re-using global directories
for storing per-app information.
For instance, if your app uses "~/.config/foo" to store configuration
data, then you can use --filesystem=xdg-config/foo, which will look
for the directory, and if it exist, let the app access it, as well
as mirror the content in ~/.var/app/$appid/config/foo.
You can also use a ":create" to enforce the directory to be created
and thus always do the mapping.
This way you can't e.g. modify your or other applications
and runtimes. If you really need to to this, your
app can explicitly request access to this directory.
If we're specifying --filesystem=/some/path, where the final element
in the path is a symlink we need to special case this. We used
to rely on bubblewrap resolving the symlink for the source and
creating a bind mount directly to that, but this does not work
if the parent directory is already visible in the sandbox, because
we can't bind-mount on top of the pre-existing symlink.
Instead we detect this the symlink early, resolve the target and
bind mount in that, then we create a real symlink in its place.
However, that doesn't work if the paren't *doesn't* exist, so
we have to check for this and not create the symlink if it is
already going to be visible in the sandbox.
This avoids an unnecessary call to flatpak_dir_modify_remote() or to
the system helper's D-Bus method ConfigureRemote, which also prevents
bothering the user to authenticate via PolKit for no reason.
Add logic in flatpak_dir_update_remote_configuration() so that the step of
configuring the local remotes after fetching the required date from the
server's summary file is performed via the system helper when present.
Note this will require the user authorizing the action by introducing
the password explicitly when asked, but this is necessary as updating
the local remotes configuration is something that can't be allowed
without explicit authentication.
It turns out that flatpak_dir_remote_fetch_summary can return TRUE,
yet leave summary_bytes NULL. The code further down does not deal
gracefully with summary_bytes being NULL, so error out early instead
of crashing.
We don't really need to create an origin remote if the same
uri is already there for an enumeratable remote, we can
just reuse that. Having multiple remotes for a single
repository just means we'll be downloading the summary file
multiple times.
Without this patch flatpak-remote-add (and anything else that uses this
section of code) segfaults if org.freedesktop.Flatpak.SystemHelper is
unavailable because it tries to cast an integer to a GDbusProxy.
Mario Sanchez Prada