Really run as non-root user in docker container

[manandbytes]

As of now,

$ docker pull ipfs/go-ipfs
Using default tag: latest
latest: Pulling from ipfs/go-ipfs
Digest: sha256:31cc5713ef3e3e81bf868cbb56c19de2d15d661743d8b6077804dee26e929ac5
Status: Image is up to date for ipfs/go-ipfs:latest

ipfs daemon will start as root user:

$ docker run --rm --entrypoint=/bin/sh ipfs/go-ipfs -c whoami
root

but later on will drop priviledges:

$ docker logs ipfs/go-ipfs |head -n 1
Changing user to ipfs

With this change applied, ipfs daemon starts as ipfs user right from
the begining:

$ docker run --rm --entrypoint=/bin/sh ipfs/go-ipfs -c whoami
ipfs

License: MIT
Signed-off-by: Mykola Nikishov mn@mn.com.ua

[whyrusleeping]

@lgierth when youre back, would be great to get your review on this

[manandbytes]

@lgierth @Kubuxu any progress?

[ghost]

Why is it better to run as non-root right away?

The advantage of starting as root and then dropping privileges, is that it makes mounting an IPFS_PATH directory easier - no need to fiddle with permissions manually, we can chown in the container if neccessary.

[manandbytes]

Why is it better to run as non-root right away?

As a user of (any) external Docker image, I want to reduce an attack surface. USER ipfs clearly communicates, just by looking at the Dockerfile, that there is n-1 problems ahead. OTOH, for the user, it is unclear if IPFS daemon actually drops privilidges, if it doing it right, ath the right time etc.

[Stebalien]

The advantage of starting as root and then dropping privileges, is that it makes mounting an IPFS_PATH directory easier - no need to fiddle with permissions manually, we can chown in the container if neccessary.

As far as I can tell, this patch doesn't prevent that. It only drops to the ipfs user right before launching the daemon. Note: this would also allow us to drop the su-exec dependency. Am I missing something?

[manandbytes]

@lgierth @Kubuxu any progress?

[Stebalien]

This should work. However, I think we should leave the current su-exec calls in container_daemon for now in case any users are manually calling start_ipfs as root.

We shouldn't need the chmod $IPFS_PATH call in container_daemon as we:

1. chmod the directory in the Dockerfile.
2. Use a volume.

[Stebalien]

(going to rebase to give this another test)

[hsanjuan]

Hi,

this broke my current integrations but I've only noticed after a new release has been tagged. The default entrypoint changed the user after it has chmod'ed the configuration folder.

docker run -v myfolder:/data/ipfs ipfs/go-ipfs:v0.4.19
ipfs version 0.4.19
initializing IPFS node at /data/ipfs
Error: /data/ipfs is not writeable by the current user
[16:02:31] ~/g/s/g/i/ipfs-cluster (master|…) $ 
docker run -v myfolder:/data/ipfs ipfs/go-ipfs:v0.4.18
Changing user to ipfs
ipfs version 0.4.18
initializing IPFS node at /data/ipfs

As pointed by @lgierth, myfolder does not exist, but is created by docker with root permissions. Before it was correctly chowned, but not anymore. It is not pretty to create a folder specifically with write permissions for the ipfs user because the ipfs user is an arbitrary user with an arbitrary uid inside the container. It made total sense that the cointainer figures out the right permissions for the volume according to whatever user it wants to run with.

I would revert this change. It added zero security while breaking things. In fact, users are now forced to pre-create and relax permissions in the provided volumes, so it probably makes things worse.