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
- Then it runs
/opt/gitlab/embedded/service/gitlab-shell/hooks/update.d/git-burn, which is a symlink to
- At this point, to operate properly,
git-burn should have read access to all files contained in the current working directory, that is,
Have you tried the system-files interface to get access to the
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
plugs: [home, removable-media, read-files]
Also, as @ijohnson noticed,
you would need to use
/var/opt is not bind mounted from the host filesystem into the snap’s mount namespace with strict confinement.
snap-confine sets current working directory to
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.