Using ~/.config rather than ~/.var/APP_ID/config

[Alexander Larsson]

On Tue, Mar 26, 2019 at 7:40 AM Michael Gratton <mike at vee.net> wrote:
>
> Hi all,
>
> I've just received a feature request for Geary to automatically migrate
> config and data from the standard XDG desktop locations (i.e. typically
> ~/.config and ~/.local/share) when first-running the app under
> Flatpak[0]. I'm sympathetic to this request, since it's weird that
> existing config and data doesn't carry across just because one installs
> an app via Flatpak rather than using traditional sources.
>
> To implement this, I'd obviously have to open a RW hole in the sandbox
> for both ~/.config/geary and ~/.local/share/geary, but once I've done
> that there's not much point copying the data across - it may as well
> just use it where it is.
>
> So I'm wondering a) if there's any reason why this would be a bad idea,
> and b) why Flatpak doesn't just do this by default?

Its a combination of things.

First of all, its a theoretical thing, we want apps to be isolated
from each other rather than mixed up in a big bundle. So, you can
delete an app and all its files and be sure that you've gotten rid of
its files (at least the internal ones, maybe not its "document files"
which are more likely in your homedir).

Secondly its a security thing. We want the default for apps to be
sandboxed and mashing all the config (etc) file from all apps together
is not a great way to do this. One app could read the others files,
etc. One could argue that you could give "only" access to the "geary"
subdirectory, but (apart from the other issues below) that is
problematic because we don't know its directory is called "geary", and
we can't just trust the app to say that it is so. Now, if you're
giving the app filesystem access *anyway* this security aspect is
uninteresting, but it is a bad idea to let such an important thing as
where to store your config files vary with a runtime option that can
change over time.

Third, its a practical issue. This doesn't really affect the geary
directory, but all sorts of libraries and things rely on the XDG dir
evn vars and use it to store stuff. Generally these things are not
designed to be shared with other instances. For example, files they
store are often not backwards and forwards compatible, so if you run
app A and it has libfoo1 bundled and then app B with libfoo2 bundled
then app B will "upgrade" the config file format, and then the version
in app A can't read it anymore. Another problem is that libraries
often store pathnames in files, and such files are inherently tied to
a particular sandbox and will break when used in another sandbox. For
example, fontconfig uses XDG_CACHE_HOME to store its font caches, and
for an app this will be the set of files it can see from its sandbox
(including i.e. bundled fonts in its app and runtime). But if
fontconfig for another app used the same cache dir it would get back
paths that it cannot see.

Now, much of these issues are "general" when running arbitrary code
that uses the XDG dirs. If you are in full control of all the code
that access a directory, such as the geary directory, then you could
take steps to ensure that this will work. However there are still
cases where it might be risky. For example, if you do the migration
you could later drop the hole in the sandbox, but if you keep it there
it will be forced to keep that hole forever (even if we come up with a
different, safer way to do the migration in the future).  Also, it is
less work as all the existing code uses glib helper like
g_get_home_config() or whatever, and suddenly you need to special case
the geary directory instead of using this.

I would recommend you migrate the config/date, but then leave a
symlink pointing into the new directory. That way host-side code can
reuse the old paths (and e.g. a host version of geary could get the
same config).