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

[Aleix Pol]

On Tue, Mar 26, 2019 at 9:35 AM Alexander Larsson <alexl at redhat.com> wrote:
>
> 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).
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak

This is a good and thorough explanation, it could make sense to have
it in a FAQ or something like that.

Aleix