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:
- First it does
cd /var/opt/gitlab/git-data/repositories/some/long/path/some-repo-name.git
.
- Then it runs
/opt/gitlab/embedded/service/gitlab-shell/hooks/update.d/git-burn
, which is a symlink to /snap/bin/git-burn
.
- 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.