We have an application that we’ve snapped that performs a git merge for us. When installed in strict mode, it doesn’t use the .gitconfig in a user’s HOME directory (as it’s redirected to the snap’s HOME).
This is problematic in the git case because the user’s name and email address are stored in the .gitconfig file, so access to the configuration file would need to be per-user.
Is there anything that can be done, or will we need to switch back to classic confinement?
Note that even if $HOME was the user’s actual home directory, the home interface doesn’t allow access to dotfiles there.
Aha, I had forgotten that. Classic it is, then.
@Odd_Bloke note that there’s a request for a dotfiles interface:
This still souds very dangerous though. Maybe a git interface would make more sense? You can ping somebody from the security team to get directions on how to confine your snap.
@Odd_Bloke, in addition to @elopio’s suggestion, you could also instruct your users to setup ~/snap/<snap>/current/.gitconfig (perhaps that setup is simply copying ~/.gitconfig there). This also means that the gitconfig can be specific to this snap.
@jdstrand Do you mean that will work after installation/for a dynamic config file?
It is pretty common to have hidden (dotted) config files in the users home!
I think the home interface should deal with that.
Maybe with a declaration fixed within the snap to avoid free access?!
This came up again here: Classic confinement for git-todos
Sure, but there are two things at play there: the information might contain sensitive information that shouldn’t be available to snaps and these dot directories are used by the programs from the hostfs and there are no guarantees that the host app and the snap command can handle each others’ configuration.
In the specific case of .gitconfig, the global .gitconfig can contain sensitive information. Please see Classic confinement for git-todos - #10 by jdstrand for a discussion of this particular issue.
