run docker container as non root user

[hamishcunningham]

This commit runs the docker container with the "build" user (id 1000) which is created in the Dockerfile.

Running as user 1000 has the benefits that:

• it is docker best practice not to run containers as root for security reasons
• files shared back to the host (via the -v option) are non-root ownership so easier to work with
• in those host distros where 1000 is the default user ID those files are owned by the current user

The potential disadvantage is for distros or customised hosts where the current user is not ID 1000. There are various workarounds in this case, or perhaps it might just be made optional and documented? (I suspect that the majority case is that people are either running a Debian derivative where the default user is likely to be 1000 or running Windows or Mac and often using a VM to allow pass-through of serial ports, in which case again often using a Debian derivative for the VM.)

Let me know what you think and I could add that...

[juancampa]

@hamishcunningham fyi - there's a conflict that needs to be resolved.

[l3nticular]

Couldn't you get the current user ID and just run as that, then your best case scenario is always.

[hamishcunningham]

hi @l3nticular I'll merge it, tnx for the heads up!. I also want to make the change an option in utils.sh, and add documentation that also covers the other ways to do this.

@juancampa yes, but it isn't easy to have the container support many IDs; the current Dockerfile creates user 1000 ("build"), so if we're also ID 1000 in the host (which is the default in debian derivatives like ubuntu) an easy win is to also run as 1000. In other projects I've had the Dockerfile create multiple IDs and do mappings of ownership back on the host but it all gets a bit messy :(

[kristiankielhofner]

I like this idea conceptually and as you note we already support running unprivileged as @stintel uses podman rootless. It's less than ideal but it is clean and a reasonable default assumption.

I've left this PR sitting here for a while to think through this hoping for some kind of elegant breakthrough ("shower thought") to occur to me but it hasn't happened yet...

I'm going to give it a little more time and try a few approaches to see how we should go about this in a more robust (but still somewhat elegant) fashion.

[hamishcunningham]

Re. robustness, @kristiankielhofner I guess that if I added something like

if [ $(id -u) == 1000 ]; then echo "will do --user build"; else echo "will print warning"; fi

then it would be a non-breaking change for any build from clean?

[stintel]

Indeed, I use rootless podman with the following command line:

podman run --rm -it --hostname=willow-builder --userns=keep-id --group-add keep-groups --volume "${PWD}:/willow" --device /dev/ttyACM0 --env PORT=/dev/ttyACM0 willow

The --userns=keep-id option maps my host UID to the same UID in the container, and --group-add keep-groups takes care of the permissions, so I can access /dev/ttyACM0.

According to the docs, one can also do --userns=keep-id:uid=1000,gid=1000, which would map the host UID/GID to the specified values in the container. Maybe there is a similar option for Docker?

I agree we should run inside the container as non-root. The only problem then is that you cannot make modifications to ESP-IDF code in /opt, which is sometimes handy to add some debug statements or so. But that's not for most users, and I'm perfectly fine running my container manually if I want to make some changes to ESP-IDF.