For compatibility with non-snap installs (migrating to/from snap) and to make user support consistent, I’d really like my snap package to be able to read/write/create a specific hidden user directory and the files within. Currently I’m using a path in $HOME/snap/… but the issues above exist.
After lots of reading and searching, my need does not appear to be possible. There is no requirement for other paths within $HOME or elsewhere and while the “home” interface would allow other paths (which are not needed) it does not allow hidden paths.
Everything else about snaps, the build process, the store etc. are great, this is my only remaining issue. So is there a way to do what I need or do I just have to accept this, from my perspective, limitation?
Currently, as you’ve discovered, there is no provision for accessing any dotfiles in $HOME (excepting limited support for .ssh in the ssh-keys and ssh-public-keys interfaces). There are no immediate plans for an interface providing the access you require that I know of, though @jdstrand might be able to weigh-in here…
It is true that this isn’t on the prioritized roadmap, however, @niemeyer and I discussed this at a recent sprint and it is recognized that sometimes a snap wants to import data from some where on install/etc. One use case is supporting deb to snap upgrades.
The ideas we came up with for a new interface are that it:
would be manually connected
would be a declarative list of paths
(perhaps) should use an installation constraint as well.
In this manner we require a snap declaration to allow connection(/installation?) of the snap. As a matter of review process, we strictly define the criteria for when the snap should be granted the declaration.
This interface is not prioritized, but if someone wanted to submit a PR to snapd, then it could be reviewed and included in snapd sooner than later. @niemeyer and I (et al) would participate in the review and design of the interface.
If someone were going to pick this up, I suggest starting with the name ‘import-path-support’. The apparmor policy would allow readonly access. Please keep in mind that the name, the security policy and example snap.yaml might be subject to change during PR review. Eg, the above assumes ‘read only imports’, but perhaps the interface should be more generalized and allow writes too.
Thanks for the information. It’s close to what I’m personally looking for but I want the user files to stay in the original location and allow the snap to read/write there. Also if the path $HOME/.foo does not exist when the snap app runs, it should be able to create it. So it’s not just for import purposes. In addition to a snap for my application, I’ve make a flatpak version too. Flatpak has the syntax “–filesystem=~/.foo:create” that does just what I need. (sorry to mention the other format). If such functionality is at all possible, I would be happy to raise a PR and be part of the discussion / testing.
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.
