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.
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.
