Created attachment 116827 [details] [review]
run: Don't override xdg home variables on full home mount

So, i actually think that this is wrong. Even if the app has access to the home directory we want all the app specific files to be stored in a single place, rather than split amongs ~/.cache, ~/.config and ~/.local/share. This is 100% true for the apps own files, but it is also the right thing for most other uses. 

For instance, we want the app to have its own copy of ~/.local/share/recently-used.xbel. And if some app-dependent libraries stores something in e.g. "~/.cache/thelib", that could break with different runtimes having different versions and configurations of "thelib" which could make these files incompatible. Thumbnails have similar issues, as the thumbnailers are per-runtime, so "failed" thumbnailings should not be global. (And in general i think we should do thumbnailing via the document portal).

That said, there are *some* things that should be used from the "real" xdg dir. For instance, it makes no sense to use per-app data for ~/.local/share/fonts (the user-installed fonts). In the particular case of fonts i just made a change to allow the users fonts to always be (readonly) visible in /run/host/user-fonts, even if you don't otherwise have $home access. I'm sure there may be a few other similar cases, but I think we need to handle those on a case-by-case basic.

For cache and config files, I agree. For data, I'm not so sure. If I start up gedit in the sandbox, I want to use the files in ~/Documents if that's exported to it. If I save a file, where does it go? By default it would be into a hidden directory that I'd only be able to find when running gedit.

I would argue that having recently-used.xbel in ~/.local/share is a bug. It seems like it's clearly a cache file.

I think you misunderstand $XDG_DATA_HOME. It is not really used for user-visible files. I mean, its not exactly well defined what goes there, but it is not "document". Just look at what some existing things put there. Things like nautilus scripts, gedit plugins, etc.

The way I see this working for gedit is:

If it has access to home or xdg-documents, it just uses a traditional file selector which can see $HOME/Documents and you save it there.

If it is sandboxed, then it will be using the document portal, which does the actual save-as dialog outside the sandbox, with full $HOME access. At the end it creates a document reference for the pathname and adds the document id to the app, which can be used to write to the file without knowing anything about it.

Sorry, you're right. I thought all the xdg user dirs derived from XDG_DATA_HOME, but that's not the case. But this is actually just our app not handling g_get_user_special_dir() returning NULL since user-dirs.dirs is not there to tell glib what the directory is. I was getting confused between the multiple xdg directories.

However, overriding XDG_CONFIG_HOME does break the user dir setup if they've customized user-dirs.dirs. E.g., I've set XDG_DOCUMENTS_DIR to ~/documents. Even if I mount my home dir within the sandbox, apps will try to use $XDG_CONFIG_HOME/user-dirs.dirs, fail, and fall back to ~/Documents.

Not sure what to do about that. Perhaps the real user-dirs.dirs could be bind mounted to the to $XDG_CONFIG_HOME if home mounts are happening.

Ah, yeah.
So, if you explicitly allow xdg-documents, then it will load the real user-dirs.dir and create a new one inside ~/.var/app/$appid/config based on that. But if you allow access to the entire homedir it does not do this. I guess we need to do this for all configured xdg dirs if the whole homedir is visible.

Moved to https://github.com/flatpak/flatpak/issues/19