@MrDogeBro so there is also the personal-files interface which you could use in that case. As stated there:
Snaps by default have access to everything under
$SNAP_USER_DATA
(eg,~/snap/<snap name>/<revision>
) and$HOME
is set to$SNAP_USER_DATA
for non-daemon commands. As a result, snaps may freely read and write to dot files in their$HOME
(ie,~/snap/<snap name>/<revision>/...
)
The
personal-files
interface is typically used to provide read-only access to top-level hidden data directories within a user’s real home directory in order to support importing data from existing applications where the snap is the clear owner of the target directory.
So I encourage you to test your snap and make sure it works as you expected. You can install it locally and check. This post gives useful hits to do so. I suggest you work locally before pushing the snap to the store until you are sure about what your snap needs and why. You could start with devmode, and then switch to strict confinement once you get such understanding. Please see this video for further details. You could also inspect variables expansion if you run something like:
$ snap run --shell hello-world.env
$ echo $HOME
/home/<user>/snap/hello-world/29
Unfortunately there are only certain categories under which classic confinement can be granted (please check the link I shared in my original response: Process for reviewing classic confinement snaps). And this is because classic confinement snaps run without restrictions, and thus, its use effectively grants device ownership to the snap. That’s why we have this rigorous review process: to make sure we can achieve the purpose of snaps being a portable and secure method for distributing applications.