fix(Dockerfile): Allow ipfs mount in Docker container

[hannahhoward]

Goals

Allow ipfs mount to be run with docker image built from Dockerfile

Implementation

-- install fuse during build phase
-- copy fusermount to smaller busybox image for run phase
-- create mount directorys for ipfs mount (/ipfs & /ipns)

For Discussion

Because a portion of FUSE runs at the kernel level, you have utilize the host machine's FUSE device: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities

This means for this command to work, you have to run:

docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse ipfs/go-ipfs

This raises the question of whether it makes sense to support ipfs mount in Docker at all. If so, we should probably update the readme, to clarify the requirements for running w/ ipfs mount

However, I wonder what use case @davidcittadini had in mind when he posted the original issue this fixes.

Also, for whatever reason, I had to actually modify the hosts permissions for /dev/fuse on Docker for Mac, but I believe this to be a Mac specific issue.

fixes #4329

License: MIT
Signed-off-by: hannahhoward hannah@hannahhoward.net

[warpfork]

It sounds like you probably already know this, but expanding on that "clarify the requirements" part: Having CAP_SYS_ADMIN (without an enclosing user namespace -- which docker does not do) is equivalent to full power on the host, including countless ways to leave the container.

I dunno if that's a concern if someone wants to run ipfs in docker for purely operational convenience reasons, but it should probably be mentioned at least briefly...

[hannahhoward]

@warpfork yep I understand. There's definitely no other way to use FUSE in a container. I want simply trying to solve #4329. I don't understand the original use case or even whether it makes sense to use ipfs mount inside of a docker container. It would be helpful to get feedback from the original issue filer @davidcittadini as to the use case

[hannahhoward]

@warpfork on the upside, none of this code requires you run docker privileged, unless you want to use ipfs mount

[eingenito]

Should we merge this along with some documentation and a warning in the readme? By default nothing would change - but it would add this capability for people who were willing to run it with elevated privs. Or should we just avoid even suggesting this use because it's a little unorthodox from a security standpoint?
@Stebalien @Kubuxu ?

[Stebalien]

I'm fine providing the option but, really, this is more @Kubuxu and @lgierth's territory.

[Kubuxu]

Should we merge this along with some documentation and a warning in the readme? By default nothing would change

I'm ok with that. As @warpfork mentioned having CAP_SYS_ADMIN is almost as good as having root on the host.

[ghost]

This looks fine to me 👍 Passing CAP_* is pretty standard, e.g. any dockerized VPN-style software usually gets CAP_NET_ADMIN.