Classic confinement for git-todos


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).


Thank you!

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:

  1. Access network to fetch issues from a remote server (i.e. GitHub). For this, I think the network interface does the job
  2. 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.
  3. 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 :slight_smile:

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 ~/snap directory.

1 Like

In practice (/home/USER/snap/ folder aside), this means:

  • :no_entry: /home/USER/.dir
  • :no_entry: /home/USER/.file
  • :white_check_mark: /home/USER/dir/.file
  • :white_check_mark: /home/USER/dir/.dir

The bottom line is you can’t access ~/.gitconfig in strict mode, unless (AFAIK) a hypothetical new interface for git is proposed and implemented or LP#1607067 is fixed. Maybe @jdstrand can comment here or in this other related thread:

1 Like

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.

1 Like

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 and (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 and for every tool :confused:

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 and configs locally.

Also @jamesh, embedding git turned out to be very easy. This is how I did it:

    plugin: autotools
      - dh-autoreconf
      - libcurl4-gnutls-dev
      - libexpat1-dev
      - gettext
      - libz-dev
      - libssl-dev

  # ...
1 Like

The first thing I’d try would be to add something like this to one of your parts:

    - git

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.