Classic confinement for git-todos

[ahmed-taj]

Hey,

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

Details: https://dashboard.snapcraft.io/snaps/git-todos/revisions/8/

Thank you!

[chipaca]

I’m not sure why it needs classic confinement: can’t it work from the snap data dir?

[ahmed-taj]

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!

[jamesh]

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?

[ahmed-taj]

Oh thanks @jamesh I forgot that part

Yes for “.git”, and “.todos.yml” itself

[jamesh]

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.

[ahmed-taj]

@jamesh

it is dot files as direct children of the home directory that are blocked

This is new to me.

The most important feature of my simple app is to generate commits hahaha

[jamesh]

You can see this in the AppArmor snippet that the home interface generates:

snapcore/snapd/blob/master/interfaces/builtin/home.go#L43-L51

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.

[robepisc]

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

• /home/USER/.dir
• /home/USER/.file
• /home/USER/dir/.file
• /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:

Accessing git config from a strict snap

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?

[jdstrand]

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 ..."
       ...
    fi
fi

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.

[ahmed-taj]

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?

[ahmed-taj]

@jdstrand

it seems like snaps like git-todos that happen to use git to store things would want snap-specific git configuration

Actually, at least for git-todos, only user.name and 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.

[jdstrand]

@ahmed-taj

Thanks for good the suggestion. Does that assume I embed git with my snap? It may work pretty well, at least for now!

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.

[ahmed-taj]

So, if the user installed multiple git-based tools, they have to configure at least user.name and user.email for every tool

I think I may need to delay publishing snap builds for now.

[ahmed-taj]

@jamesh

While you could embed a copy of git into your snap might help with (3)

May you please give some hints to embed a git inside my snap?

[ahmed-taj]

OK, thank you all folks!

I ended up providing snaps with “strict” access. I also documented that you need to set user.name and user.email configs locally.

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

parts:
  git:
    plugin: autotools
    build-packages:
      - dh-autoreconf
      - libcurl4-gnutls-dev
      - libexpat1-dev
      - gettext
      - libz-dev
      - libssl-dev
    source: https://github.com/git/git/archive/v2.15.1.tar.gz

  # ...

[jamesh]

@ahmed-taj

May you please give some hints to embed a git inside my snap?

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

stage-packages:
    - 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.

[jdstrand]

@ahmed-taj

I ended up providing snaps with “strict” access.

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.