May you please grant git-todos classic confinement ?
It’s a Command Line Interface (CLI) that helps to manage local To-Dos, but it needs to read/write the .todos.yml file and interact with Git (to get repo root, perform commits …etc).
I’m not sure why it needs classic confinement: can’t it work from the snap data dir?
The .todos. yml are stored inside repository root dir which can be anywhere. But the thing I really concerned about is can the snap run external commands (typically git ) with strict confinement?
For the .todos. yml I think I may limit the access to only user’s home , but what about git ?
Edited: @chipaca correct me if I’m wrong.
The app basically needs the following permissions:
- Access network to fetch issues from a remote server (i.e. GitHub). For this, I think the
network interface does the job
- Read/Write access to the disk (at least the user home) and for this, the
home interface is enough. I could provide a tip not to store things outside the home dir in the docs.
- Ability to execute the
git command, for which I couldn’t find a suitable inteface
That’s why I need a classic confinement!
While you could embed a copy of git into your snap might help with (3), you wouldn’t have access to the user’s
~/.gitconfig file (the
home interface doesn’t give you access to dot files). Is that likely to make a difference for your tool?
Oh thanks @jamesh I forgot that part
Yes for “.git”, and “.todos.yml” itself
I don’t think there would be any problem accessing those directories inside the repository: it is dot files as direct children of the home directory that are blocked. So
~/.gitconfig is blocked, but
~/src/someproject/.todos.yml should be fine.
I think the most obvious thing you’d miss with access to
~/.gitconfig being blocked is access to the user’s committer ID if you need to make new commits.
This is new to me.
The most important feature of my simple app is to generate commits hahaha
You can see this in the AppArmor snippet that the home interface generates:
The first line allows access to files and directories under the home directory that don’t start with a dot or the letter
s. Then the following rules allow access to files and directories starting with
s, but avoiding the
Note that ~/.gitconfig can contain sensitive information and while I’m not saying that an interface can’t be created for it (or more probably, the home interface adjusted in some manner), we should think through this. Suppose ~/.gitconfig is exposed via an interface. Because .gitconfig can contain sensitive information, we would make the interface manually connected. Anything using git (like git-todos) would almost certainly request an auto-connection of the interface so all these git-using snaps would have access to the sensitive information. While I could see a git command snap needing to use this interface, it seems like snaps like git-todos that happen to use git to store things would want snap-specific git configuration.
In that light, can git-todos (and other similar snaps) simply use $HOME/.gitconfig (which evaluates to ~/snap/git-todos/SNAP_REVISION/.gitconfig)? The snap could do something like:
if [ ! -e "$HOME/.gitconfig" ]; then # $HOME is $SNAP_USER_DATA here
echo "Creating default git configuration in $HOME/.gitconfig"
touch "$HOME/.gitconfig" # could also ask some questions to populate .gitconfig
REAL_HOME=$(getent passwd $USER|cut -d ':' -f 6)
if [ -e "$REAL_HOME/.gitconfig ]; then
echo "Detected '$REAL_HOME/.gitconfig'. You may want to ..."
In this manner, your snap has just the git configuration it needs and other snaps have just the git configuration they need, while the global configuration is intact. Alternately, pass
--local to git config (man git-config) and in your project directory and it will use .git/config.
Thanks for good the suggestion. Does that assume I embed git with my snap? It may work pretty well, at least for now!
Edit: Just curious? how snap handles e.g. multiple git-based snaps all embedding git?
Actually, at least for git-todos, only
user.email (which are usually stored globally) are required to perform a commit. Nothing specific to git-todos at all it only run “git commit -m ‘autogenerated message here’” nothing else.
Yes. In strict (and devmode) your snap runs in a different runtime environment than the classic system that is based on the core snap (currently). This snap doesn’t have git in it so you will have to ship it yourself.
As for snapd handling multiple git-based snaps embedding git, it handles it fine in terms of keeping everything separate which is good cause people can ship whatever they want and not have to worry about breaking stuff or being broken. In terms of duplication, snapd does not currently do any deduplication.
So, if the user installed multiple git-based tools, they have to configure at least
user.email for every tool
I think I may need to delay publishing snap builds for now.
May you please give some hints to embed a git inside my snap?
OK, thank you all folks!
I ended up providing snaps with “strict” access. I also documented that you need to set
user.email configs locally.
Also @jamesh, embedding
git turned out to be very easy. This is how I did it:
The first thing I’d try would be to add something like this to one of your parts:
This will cause snapcraft to download the named .deb and its dependencies, and extract them for you. In addition to this, you will probably need to set the GIT_EXEC_PATH environment variable so git can find its sub-commands.
FYI, your snap is passing automated reviews now. For some reason r41 and r42 got hung up. I retriggered the review and they both passed, but you’ll need to release them to a channel.