Mount CVMFs in container without access to docker options

Client
1

For my Gitlab CI jobs I’m using Docker containers with a CVMFS client mounting my repository. This works fine as long as the container that runs the CI job is started with the usual set of docker options needed to make CVMFS work properly from inside the container, e.g.:

--device /dev/fuse --cap-add SYS_ADMIN --security-opt apparmor:unconfined

This requires to tweak the gitlab-runner config file by adding some options like:

    cap_add = ["SYS_ADMIN"]
    security_opt = ["apparmor:unconfined"]
    devices = ["/dev/fuse"]

to the runner configuration.

All of the above pose no problem as long as one have access to the runner host and enough permissions to configure gitlab-runner, but falls short with e.g. shared runners. Is there any way to circumvent the problem, i.e. to mount CVMFS inside a container on a system where there’s no possibility to specify docker options? Needless to say, mounting CVMFS on the host and then bond-mounting inside the container is not an option.

2

Maybe GitHub - cvmfs/cvmfsexec: Mount cvmfs repositories as an unprivileged user will do what you want, although that also needs /dev/fuse.

3

Currently it is not possible to bind mount devices in a Gitlab CI job, that requires configuring gitlab-runner as well so cvmfsexec is not a solution if it still requires to bind mount /etc/fuse. There is progress in adding the possibility to mount volumes in a Gitlab CI job but it seems that bind mounts could not be supported.

4

The cvmfs client is based on fuse so you’re pretty much out of luck if you have no access to /dev/fuse.

The only other potential solution is parrot but that has a lot of other downsides.

5

Thank you, Parrot seems nice but a significantly different workflow from what I have already implemented. I’ll take a look.

6

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.