Request for classic confinement: git-burn

store-requests
1

GitHub, Snapcraft.

This snap should be able to read files in /var/opt/gitlab/ which is home directory for git service user in GitLab. This is not currently possible since home paths are hardcoded in snap-confine.

Somewhat related problems from the user perspective are discussed here:

3

Have you tried the system-files interface to get access to the /var/opt/gitlab path? For consideration of the classic confinement request it will be helpful for you to describe why you need access to what looks initially to be a third-party application’s files. Also, please describe why the provided interfaces are insufficient to gain access to the paths you need (check the system-files interface to see if it suits your needs). Are there any other reasons you feel classic confinement is required besides access to the gitlab files?

4

Note that to use the system-files interface you would need to use /var/lib/snapd/hostfs/var/opt/gitlab since /var/opt is not bind mounted from the host filesystem into the snap’s mount namespace with strict confinement.

1 Like
5

For consideration of the classic confinement request it will be helpful for you to describe why you need access to what looks initially to be a third-party application’s files.

This is a server-side git hook for linting, so it is supposed to be invoked by some third-party repository management application like GitLab Shell, Gitea, gitolite, and so on. Therefore, it should have at least read access to the repositories managed by that app.

For example, this is how GitLab Shell performs hook invocation:

  1. First it does cd /var/opt/gitlab/git-data/repositories/some/long/path/some-repo-name.git.
  2. Then it runs /opt/gitlab/embedded/service/gitlab-shell/hooks/update.d/git-burn, which is a symlink to /snap/bin/git-burn.
  3. At this point, to operate properly, git-burn should have read access to all files contained in the current working directory, that is, /var/opt/gitlab/git-data/repositories/some/long/path/some-repo-name.git.

Have you tried the system-files interface to get access to the /var/opt/gitlab path?
please describe why the provided interfaces are insufficient to gain access to the paths you need (check the system-files interface to see if it suits your needs)

Yes, I have tried the systems-files interface. For example, consider the following fragment of snapcraft.yaml:

apps:
  git-burn:
    command: git-burn
    plugs: [home, removable-media, read-files]
plugs:
  read-files:
    interface: system-files
    read: ["/var/lib/snapd/hostfs"]

Also, as @ijohnson noticed,

you would need to use /var/lib/snapd/hostfs/var/opt/gitlab since /var/opt is not bind mounted from the host filesystem into the snap’s mount namespace with strict confinement.

However, snap-confine sets current working directory to /var/lib/snapd/void, so git-burn has no means to determine the original working directory (i.e. /var/opt/gitlab/git-data/repositories/some/long/path/some-repo-name.git) in which it was started by GitLab Shell or any other similar repository management app.

Are there any other reasons you feel classic confinement is required besides access to the gitlab files?

Besides that, there are no other reasons.

6

Can you enumerate all expected locations for other git server software to store their repositories (i.e. GitLab stores it in /var/opt/gitlab/...)? We could pursue some kind of git-server-files interface which sets up a bind mount from the host’s /var/opt/gitlab to the snaps mount namespace to allow your snap to access these directories. Also, if these directories are configurable and/or arbitrary then setting up this kind of interface will probably not work, but if the directories are always the same it’s conceivable.

7

Can you enumerate all expected locations for other git server software to store their repositories

To the best of my knowledge:

  • GitLab: /var/opt/gitlab/git-data (configurable)
  • Gitea: /home/git (already covered by home interface)
  • Gitolite: /var/lib/gitolite (configurable)
  • These locations are also sometimes used: /var/cache/git, /var/lib/git, /var/git/, /srv/git, …

Also, if these directories are configurable and/or arbitrary then setting up this kind of interface will probably not work, but if the directories are always the same it’s conceivable.

These directories are mostly configurable. For example, in GitLab: Repository storage paths.

8

I think classic is probably the best way forward for this since the directories are configurable. This also would match other similar git tools, but for a different reasoning than git cola for example (see Classic Confinement Request for the git-cola Snap).

9

I agree with @ijohnson that as of today this needs to be classic, though it is a shame since it sounds like all it really requires is read access to those files in /var. The issue with /var/lib/snapd/void is interesting since snap-confine is doing that because you are in a directory that doesn’t exist within the snap’s runtime environment. It’s conceivable in this situation we could export a SNAP_PREVIOUS_CWD that had the path with /var/lib/snapd/hostfs prepended. Between this and @ijohnson’s idea of having a bind mount interface, the requirements are understood for a possible future enhancement to snapd to accommodate this use case.

@advocacy - can you perform the vetting?

1 Like
10

@jdstrand vetting done, +1.

11

Granting use of classic. This is now live.

1 Like