Ceedling docker container should not use root as default user

[Letme]

There was some discussion in another issue about how to run Ceedling using docker containers and it was advised to use the root user. I am not certain how container was done as there's no Dockerfile in this repo, but we should not promote usage of root user inside the docker container, especially since artifacts created by docker container are used by host user (uploaded, debugging,etc).

Solution is to create a user inside the docker container (lets say developer - command is USER) and use that (I think installation of gem will also need to be done as that user. Then the build directory will not be owned by root (uid 1) but by that user (uid:1000) which in most cases is also an initial user of host system. That way files created within docker container have uid and gid 1000 and not 1 as they do with root and user can delete them without using docker container cleanup (ceedling clobber or ceedling clean).

The usage of --user command is a bit of a bypass. It uses root user inside the docker container, but that is mapped as current user and group on host. I have added that part to the README (as I could contribute), to at least a bit educate the people. The command is only tested on Linux, but I also amended the line for Z-shell, which I did not test.

[mkarlesky]

@Letme The Docker container does not use root as a user. A non-root user dev was created for the Docker image. This is why the default project workspace is /home/dev/project. It is not possible for object files generated in a container to be owned by root as root is not the active user in the container.

The only reason you saw -u root in a recent support issue is because of the fact that the Docker container does not default to a root user. As such, it's not possible to install things in the running Docker container. Adding -u root is a standard Docker feature and is a security bypass that is left up to the user. If someone chooses to use it, the security implications are on them.

The nature of Docker and its typical installation gives it privileged access that can be taken advantage of in any number of ways that a Docker container has no influence on. We've implemented the basic security best practices of a non-root user, using a small and well-patched base image (minideb), and limiting image contents to only what is needed (this is why there are 4 versions of the Docker image from minimal to maximal).

The Dockerfiles live in a separate repo. There's more work on automating their generation and on documentation. One addition will be scripts to help users wrap their docker run commands and set the dev user's group ID to match that of the host user. This is the simplest and most secure way to handle host system permission issues. We just haven't gotten there quite yet. We released 1.0.0 with only minimal Docker image documentation, favoring getting out 1.0.0 as so many were begging for it.

At any rate, the intricacies of using the Docker images is best documented in their repo and in their Docker Hub repositories with links from Ceedling. That's what we will do when those things are available. There's a ton to be done on documentation still — especially in porting it all over to a proper documentation system of some sort. I don't want to add even more documentation to an already heavy README and CeedlingPacket for Docker use when that content should live somewhere else and will only be of interest to Docker users.

[Letme]

OK, my bad then, sorry for the wasted time. I did not run the Ceedling Docker container before I proposed the change (I install gem in my CI) and I was originating from the wrong initial premise. The user flag to docker just makes sure it aligns with user inside container (in this case dev), so files produced by docker have same uid and gid as the user running the docker. Since this is not needed, I will just close the PR.

[mkarlesky]

@Letme I appreciate your concern and recommendations. In fact, the previous image does default to a root user, and there has been entirely appropriate calls for fixing that. This was one motivation for a much different approach to Docker containers this time around.