Slight offtopic: Could something similar be done for snaps such as IntelliJ Idea which wants access to some specific dotfiles? Unlike ssh and gpg keys which are “well-known”, those are IntelliJ-specific.
Would a “dotfile-access” interface which can be parameterized with the specific directory each application needs, to avoid giving shotgun access to all dotfiles.
Anyway, just an idea.
I’ve split the question out of the mosh conversation as it’s indeed off-topic for it.
We can eventually introduce something similar to that “dotfile-access”, but it’s not something I would do so lightly and without careful consideration of side effects. The main problem with that is it misses the semantic intention of accessing those files.
The proposal in the other topic was to introduce ssh-keys and gnupg-keys interfaces, and both of these have a very clear goal: there’s some well known and important data in an arbitrary location of the system (it doesn’t matter much that it’s a “dot directory”) and multiple snaps may want to access it for obvious reasons that may be easily evaluated as making sense or not considering the application nature.
But we don’t want that happening for every single application just because it wants to access the data inside the user’s home instead of under the $SNAP_USER_DATA directory as encouraged today. Doing so would miss some of the benefits that snaps introduce, such as proper reverts, snapshots soon, and also would make the security model more complex because these directories often contain means that might allow breaking out of the sandbox if run by applications outside the snap.
So, for the particular case at hand: what are the requirements for IntelliJ more specifically?
Hi! I’m just bringing this up because I happened to see the IntelliJ classic request for, essentially, only their application’s data directory, so I don’t know more specifics. maybe @Jonas can give us more details?
Clearly the application itself could be taught to look in $SNAP_USER_DATA though that entails work on their side.
If it’s OK to grant classic to applications with the understanding that they’ll move towards $SNAP_USER_DATA and full confinement later, then I agree we don’t need the specific “dotfile-access $SOME_APP” interface.
But it’d still be good to encourage developers to see this as an interim measure, otherwise everybody will want to use “classic” with these precedents and those benefits you mention (and confinement!) will still be lost to the majority of apps.
Thanks!
$HOME is already set to $SNAP_USER_DATA so there’s really no work needed for typical applications. We also don’t recommend classic confinement to applications that simply want to store their files under a dot directory in $HOME.
If $HOME is set to $SNAP_USER_DATA, why does IntelliJ not work then? It still tries to access “$HOME”.
Someone familiar with the snap would have to investigate what’s going on there.
It is not evaluating $HOME but instead coming up with another way to determine the user’s home. I suspect it is either hardcoding /home/$USER (or something equivalent) or using getent passwd/getpwent(). Like Gustavo said, someone would have to look.
It occurred to me the snapcraft preload could be made to catch getpwent() and shove $SNAP_USER_DATA in the passwd struct.
Looking into the source code provided with IntelliJ IDEA Community there is a file called idea.properties. Among others, it contains
# idea.config.path=${user.home}/.IdeaIC/config
# idea.system.path=${user.home}/.IdeaIC/system
which looks like what we want. It however looks like it does not use “$HOME”. The user.home property is set by Java to probably the wrong path, e.g. /home/myname. Seems like a Java Bug.
Is there a way to patch this file when running snapcraft?
I’m sure there’s a way to tune those values to point to $SNAP_USER_DATA.