Looks a bit more painful than just loading fuse in the container. By default, docker containers can't mount arbitrary filesystems.

The last comment on https://github.com/docker/for-linux/issues/321 says the following:

The following steps work for me on Fedora 32 to use FUSE in a Docker container without --privileged or --cap-add SYS_ADMIN:

• Patch the seccomp profile to drop the restriction on clone(2) namespace flags and allow mount(2) and umount(2): https://gist.github.com/juergbi/44b0e7aaa50742f996eed0693e053cda This is a patch for profiles/seccomp/default.json as available in the docker/moby repositories.
• Ensure the fuse module is loaded
• Run the Docker container with the options --device /dev/fuse --security-opt seccomp=/path/to/fuse.json
• In the Docker container run unshare -c --keep-caps -m to open a shell in new unprivileged user and mount namespaces.
• In that new shell it's then possible to mount and use FUSE. E.g., sshfs user@host:directory /mnt

Depending on the uid mapping Docker uses, this can be considered secure as long as you trust the kernel implementation of unprivileged user namespaces (and FUSE). It would be great if this was supported by default or at least as an easy-to-use alternative profile.

Side-note: To allow mounting tmpfs in the user namespace in the container, Fedora additionally requires --security-opt label:type:container_userns_t (SELinux).

I guess we can try to do that somehow, but I'm not quite sure how to unshare within the container /with/ the Jenkins docker integration.

I made some test locally, adding the options --privileged, --device /dev/fuse and --cap-add SYS_ADMIN is working :

➜  swh-fuse git:(arcpatch-D4064) ✗ docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock -v ~/wip/.arcrc:/home/jenkins/.arcrc -v /usr/bin/docker:/usr/bin/docker -u jenkins:docker  --entrypoint bash --name jenkins --device /dev/fuse  --privileged --cap-add SYS_ADMIN swh-jenkins/tox
jenkins@ea69ee0a007f:~$ git clone https://forge.softwareheritage.org/source/swh-fuse.git
...
jenkins@ea69ee0a007f:~/swh-fuse$ arc patch D4064
...
jenkins@ea69ee0a007f:~/swh-fuse$ tox
..
collected 4 items                                                                                                                          

.tox/py3/lib/python3.7/site-packages/swh/fuse/tests/test_cli.py .                                                                    [ 25%]
.tox/py3/lib/python3.7/site-packages/swh/fuse/tests/test_content.py ..                                                               [ 75%]
.tox/py3/lib/python3.7/site-packages/swh/fuse/tests/test_directory.py .  
...
  black: commands succeeded
  flake8: commands succeeded
  mypy: commands succeeded
  py3: commands succeeded
  congratulations :)

I continue the tests with seccomp to be more fine grained in the capabilities management. IMO, the main problem using a patched seccomp file is this file is changed at almost each version of docker and it may add some maintenance cost to maintain our file always up-to-date.

In fact after others tests, only the device and the --privileged option are necessary as runnin in privileged mode completely disable seccomp.

With `--cap-add SYS_ADMIN` but without the privileged option, the tests are failing

I failed to successfully execute mount on the container without the privileged option so I finally configured the swh-fuse job with this option.

(note: I'm not confortable with the jinja syntax so I'm not sure it's the best way to do this, but the tests on the swh-jenkins-jobs look ok)