I want to have my app config to be in /home/user/.config/app/ or $XDG_CONFIG_HOME/app/, but snap doesn’t allow an app to access this directory. How can I grant access to read exactly this directory?
If your snap uses a desktop extension (i.e. the gnome one) it will properly set up all required XDG directories:
ogra@styx:~$ snap run --shell snap-store -c "env|grep XDG_CONFIG_HOME"
XDG_CONFIG_HOME=/home/ogra/snap/snap-store/1249/.config
ogra@styx:~$
is there any particular reason you want the config dir to live outside the snap space ? i.e. do you expect people to run the same app as deb and snap package on the same machine so they can share their config ?
Technically you can request access to such a dir through the personal-files interface but i’d consider twice if this is really necessary … (the pre-selected XDG dir is automatically included in rollbacks of the snap for example and also automatically used by the built in snapshot feature that people might be using for backups, not using it will cut your snap down in features)
Having all config files in one place is very handy when it comes to synchronization, backups, troubleshooting, stability, standards, scripts etc. In general giving an app access to some directory/directories seems like a basic idea for me: sandbox everything except for this/those. If I want to give an app access to 1 directory, why should I give it access to all of my non-hidden and/or hidden files in /home/user? In the end, app might not support personal-files or other interfaces, so I can’t add access conveniently. Is there a way for this to work?
P.S. Snapshots are great for stability, but config is at stake: app removal will lead to config being moved away from ~/snap/app/ and app purging will lead to deletion of config.
Not sure what you mean by this, the interface has nothing to do with the app, it simply grants access to the directory you define (i.e. $HOME/.config/app), the app will simply just use it as it would un-sandboxed…
A simple snap remove <app> always takes a snapshot of the user data of the snap by default and that snapshot will be restored when you re-install the snap so that the configuration persists between remove/install operations but does not clutter your disk …
Only if you use the --purge option to the remove command it will not use the snapshot feature…
If you use the personal-files way to have an un-sandboxed config, you will have to write a script to clean up the config after you, else it will forever clutter your users disk and you will have to make your app deal with any discrepancies in the config when your user does a roll-back with snap revert ...
As a user you can’t just connect any plug, as described here - you need previous work from developer. Needed approach can be seen here, but this configuration is not integrated in snap apps by default.
Can configuration files clutter disk more than snaphots? Configs can be dealt with easily - just take a look at .config/app and delete it if you need to.
Because of this issue such an option should be opt-in by default with some warnings popping out when snap revert is used. In case of config errors you would be able to unplug it and have vanilla config from snap directory.
Well, it is actually the user who connects them, but yes, you as a packager need to set this up for your app during snap creation… (FWIW, after the interface was granted to your snap you can ask for auto-connection, if your app is the clear owner of the dir a user won’t have to do anything)
Transactional updates with automatic Roll-Back on failure is an essential part of the snap ecosystem, most packagers understand this and simply create their snap in a way that it can make use of these features … This is definitely not an opt-in feature