As an important detail of that interface which was quickly mentioned by Jamie, that interface won’t be able to be manually connected. The problem here is that as it stands a user would have no ability to evaluate whether the data being offered to the snap is indeed supposed to be used by that snap. For example, the interface might be named “pictures” but the paths might be “~/.ssh” or “~/.gnupg”. So this would indeed be used only on exceptional cases, and would need to pass through review first.
In the future we can lift that restriction by making interfaces more interactive. We’d need to prompt the user to accept the fact that the specific requested paths are being granted to the application, at connection time.
@pjbroad The interface suggested would effectively give what you’re asking for. The detail is that it’d need to pass through review first, which shouldn’t be a problem for you I assume. The other detail is that by not using the usual snap conventions, your snap will probably misbehave on rollbacks when there are data format differences.
@niemeyer Sounds good. The code for my app is open source so a review could look as deep as required. The user data here is pretty simple and we already consider compatibility between versions. For the existing snap, I already store user data in the common tree rather than in the current tree because a user would not want their data rolled back with app versions. This is a game with quest information and such so rolling back would be very bad. Storing outside of the snap tree, as this proposal would allow, also has the advantage (as I see it) of not deleting user data if the snap is uninstalled, though I have read of the plans for backups which sounds great.
Note to @reviewers - while an app may be open source, there is nothing saying that the claimed source code was used to generate the snap. With the recent addition of a link to the build log in the reviewers interface of the store for LP-originated (ie, snapcraft.io) builds, we have a number of things that can be considered during reviews: verifying the publisher, verifying the source, verifying uploads are coming from trusted builders and verifying those build logs.
@evan, @Wimpress, @popey, @niemeyer : along those same lines, I think it would be wonderful if a user of a snap had some way to find the public build logs. Many times I’ve seen comments that people can’t trust a snap cause they don’t know the publisher and there is no way to verify the snap’s contents when it claims to be open source. AFAICS, while the build log is public, finding it is difficult at best. I’m not sure where that should live, so mentioning it to all of you; somewhere off https://snapcraft.io/<snapname> seems reasonable OTOH.
Agree with your points. I just don’t see the relation between making build logs more visible and your overall point about source being declared open doesn’t mean trusted. Having the build logs available won’t change that, right?
This was an aside that I probably should have introduced in another topic. Having the build logs available in and of itself doesn’t mean an arbitrary publisher should be trusted, but it does provide a data point in the users choice to install the snap. Public build log availability could be added to a list of criteria that the reviewers use, if we chose to adjust our processes for that at some future point.
A workaround is to ask the user to create a hard link from the real path to the snap path manually in a launcher:
nano-launch: It appears that you have a nanorc file in your home directory, however due to snapd's security confinement it is not accessible by the snap.
nano-launch: If you wish to use it you have to create a hardlink manually by running the `ln /home/buo-ren/.config/nano/nanorc /home/buo-ren/snap/nano/common/.config/nano/nanorc` command in a terminal.
nano-launch: To silent this warning without linking create a blank file at /home/buo-ren/snap/nano/common/.config/nano/nanorc.
Press Enter to continue:
Hi, I also believe that Snap should provide a way to access the host XDG folders.
I know that this is mainly a requirement for desktop applications, but I believe it is a big issue that currently is not possible to switch to/from Snap without loosing all your app data (just think about apps that have profiles or saves).
Snaps can request access to the default XDG folders via the personal-files interface, and apps have access to the environment variables to determine whether the user has e.g. set $XDG_CONFIG_HOME to something different than the default. If the user points $XDG_foo to a dotfile different from the one requested via personal-files, that’s not supported. And indeed the runtime configurability implied by setting $XDG_ environment variables is the reason for things not quite being as easy as you’d expect.
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?
As said in #17, the use case is allowing the user to switch freely and smoothly from and to Snap.
Possible use cases are:
I install GWE from Flathub, I create my custom fan profiles, I uninstall Flatpak GWE and install Snap Store GWE, I still have my profiles.
I install GWE from Snap Store, I create my custom fan profiles, I uninstall GWE, I reinstall GWE, I still have my profiles (maybe this is already covered by $SNAP_USER_DATA)
And other combinations using different package managers and sources for the app.
Then imagine you made (intentionally or not) backward incompatible change in app config. Now switching between different app installation sources could make shared configs broken (snaps even make effort to keep separate config for each app version).
This also breaks sandboxing guarantee as normally app can’t access other apps configs in snap/flatpak if they’re stored in designated directory but not if you set it up like you want.
@Reynolds5 I understand your POV but I still believe that it should be possible to do it if a developer want to take the challenge of maintaining backward compatibility for his $XDG_CONFIG_HOME.
Just to clarify: I don’t want this behavior to be changed for all the apps, I just want to be able to use it if needed.
That would break my app because it relies on creating profiles and keeping them between app upgrades.
