I would like to use the $XDG_CONFIG_HOME to access the default user-specific configuration directory, in my case /home/leinardi/.config/, but when I try to access it from Snap I get this other directory: /home/leinardi/snap/gwe/x1/.config/
Is there a way for me to let $XDG_CONFIG_HOME return and than access the host folder?
Hi @leinardi,
Hidden files/directories are not accessible for security reasons, see Access to specific hidden file path in users $HOME for a discussion on the topic.
Thanks, I posted a comment there to say that XDG folders should be supported, independently if they are inside an hidden folder or not.
Could classic confinement help with this?
Snapd 2.37 shipped two new interfaces, one of those can be of use, specifically the personal-files interface. https://docs.snapcraft.io/the-personal-files-interface/9357 - it still doesn’t give you easy access to XDG documents in the traditional sense because those can freely move around (as in, they are defined through complex logic involving multiple files and environment variables). If an application truly wanted to access a specific XDG folder reliably it would probably have to involve a new interface. In addition it would probably involve per-user mount namespaces. Even then it would react poorly to any changes in location (e.g. by using one of the mechanisms to redefine where .config is.
Hey thanks a lot for the reply, @chipaca suggested the same thing in the post linked by @Saviq.
This could be a possible workaround for all the users with .config as $XDG_CONFIG_HOME but I am not sure how can I use it.
Should I do something like this?
plugs:
personal-files:
write: [ $HOME/.config/gwe ]
read: [ $HOME/.config/gwe ]
Can I then force the $XDG_CONFIG_HOME of my Snap to be $HOME/.config (currently it points to $HOME/snap/gwe/x1/.config/)? If yes, how?
If the folder $HOME/.config/gwe does not exist already, can it be a problem? Am I allowed to create it from my snap? Would a normal mkdir -p $HOME/.config/gwe work from inside the snap?
@leinardi Why do you need $XDG_CONFIG_HOME access? Snaps deliberately store their dotfiles in $HOME/snap/$APP_ID (the same way as flatpaks store them in $HOME/.var/$APP_ID to prevent messing with configs that come from the apps installed directly on host. Trying to undo this is like swimming against the tide and almost certainly not what should be done.
For what I can see Flatpak handle $XDG_CONFIG_HOME in a completely transparent way: my Flatpak instance can access the same $XDG_CONFIG_HOME folder (/home/leinardi/.config/gwe) as if I run the app directly on the host. Flatpak and host app share the same $XDG_CONFIG_HOME folder with 0 code changes needed on app side. This is my current manifest.
I explained the reason why this is needed here.
Flatpak always sets $XDG_CONFIG_HOME to $HOME/.var/app/$APP_ID. I see you don’t use any --filesystem= permissions so I have no idea how you are accessing /home/leinardi/.config/gwe, that looks like sandbox escape.
Anyway sandboxes are designed in a way to prevent access to arbitrary directories without explicit permission and host’s $XDG_CONFIG_HOME is totally arbitrary directory. If users want to share configs then they may copy them themselves, there is no need to force them.
I just tested your app from flatpak and it uses $HOME/.var/app/com.leinardi.gwe/config for its config storage as expected. There is something missing from info you provided. Did you add any overrides locally? What’s output from flatpak info -M com.leinardi.gwe.
EDIT: Theoretically you may add --filesystem=~/.config/gwe:create permission to achieve what you wanted but this isn’t much welcomed in flatpak as one reviewer stated:
it also breaks some expectations of Flatpak users that applications are entirely self-contained and can be cleaned up completely by removing ~/.var/appid
Ok, looks like you are right and I, just by pure chance, had the same profile on both .config/gwe and .var/app/com.leinardi.gwe/config. And I probably have misinterpreted the ‘just work’ from the conversation I had on the flatpak’s irc channel:
<leinardi> hey guys, more questions: when I install the flatpak I see these file access rules: file access: home:ro, xdg-run/dconf, ~/.config/dconf:ro
<leinardi> but I need to save data on $XDG_CONFIG_HOME, is this ok or should I use different permissions?
<nanonyme> Would it be enough to persist the data inside app sandbox?
<leinardi> do I need special rules or the $XDG_CONFIG_HOME would return already the right one?
<nanonyme> Do you have any --persist switches?
<nanonyme> TingPing probably knows these better than me though...
<leinardi> not sure what they are but I can't find any occurrence in my project (manifest included)
<nanonyme> That .config is also a bit wonky since inside sandbox you mose likely XDG_CONFIG_HOME pointing to config and not .config
<nanonyme> Most like have even
<nanonyme> TingPing, did you get any further with the settings portal?
<TingPing> nanonyme, just waiting on glib changes
<TingPing> leinardi, if you don't use gsettings in your app then you won't need dconf
<TingPing> leinardi, but i'd suggest you use gsettings... its a nice api
<leinardi> TingPing, I need $XDG_CONFIG_HOME to store a sqlite db containing all my persistent data, I use ORM and, unless gsettings privide support for one, I don't think I would want to switch to it
<TingPing> leinardi, fair enough. well everything should 'just work' for you
<leinardi> TingPing, nice! thanks :)
Since I ended up with the same profile on both host and flatpak, I wrongly assumed it was using the same folder. Sorry about the confusion.
Now I’m not so sure what to do, but I still like the idea of using the same profiles no matter from where you install the app.
FYI, at one point we considered setting things like XDG_CONFIG_HOME=$SNAP_USER_DATA/.config but it was rejected at the time since things that we currently allow would break (eg, ibus, fcitx, pulse cookies, gtk-* settings, gsettings/dconf).