Issue #230 - Do not use root user in container

Author: ppodgorsek

.travis.yml

@@ -32,3 +32,8 @@ script:
 
   - docker run --shm-size=1g -v `pwd`/test:/opt/robotframework/tests:Z -e BROWSER=chrome -e ROBOT_THREADS=4 -e PABOT_OPTIONS="--testlevelsplit" docker-robot-framework:ci
   - docker run --shm-size=1g -v `pwd`/test:/opt/robotframework/tests:Z -e BROWSER=firefox -e ROBOT_THREADS=4 -e PABOT_OPTIONS="--testlevelsplit" docker-robot-framework:ci
+
+  - docker run --user=2000 --shm-size=1g -v `pwd`/test:/opt/robotframework/tests:Z -e BROWSER=chrome docker-robot-framework:ci
+  - docker run --user=2000 --shm-size=1g -v `pwd`/test:/opt/robotframework/tests:Z -e BROWSER=firefox docker-robot-framework:ci
+  - docker run --user=2000:2000 --shm-size=1g -v `pwd`/test:/opt/robotframework/tests:Z -e BROWSER=chrome docker-robot-framework:ci
+  - docker run --user=2000:2000 --shm-size=1g -v `pwd`/test:/opt/robotframework/tests:Z -e BROWSER=firefox docker-robot-framework:ci

Dockerfile

@@ -4,15 +4,13 @@ MAINTAINER Paul Podgorsek <[email protected]>
 LABEL description Robot Framework in Docker.
 
 # Set the reports directory environment variable
-# By default, the directory is /opt/robotframework/reports
 ENV ROBOT_REPORTS_DIR /opt/robotframework/reports
 
 # Set the tests directory environment variable
-# By default, the directory is /opt/robotframework/tests
 ENV ROBOT_TESTS_DIR /opt/robotframework/tests
 
-# Set up a volume for the generated reports
-VOLUME ${ROBOT_REPORTS_DIR}
+# Set the working directory environment variable
+ENV ROBOT_WORK_DIR /opt/robotframework/temp
 
 # Setup X Window Virtual Framebuffer
 ENV SCREEN_COLOUR_DEPTH 24
@@ -23,6 +21,10 @@ ENV SCREEN_WIDTH 1920
 # By default, no parallelisation
 ENV ROBOT_THREADS 1
 
+# Define the default user who'll run the tests
+ENV ROBOT_UID 1000
+ENV ROBOT_GID 1000
+
 # Dependency versions
 ENV ALPINE_GLIBC 2.31-r0
 ENV CHROMIUM_VERSION 81.0
@@ -99,8 +101,24 @@ RUN apk update \
 
   && apk del --no-cache --update-cache .build-deps
 
+# Create the default report and work folders with the default user to avoid runtime issues
+# These folders are writeable by anyone, to ensure the user can be changed on the command line.
+RUN mkdir -p ${ROBOT_REPORTS_DIR} \
+  && mkdir -p ${ROBOT_WORK_DIR} \
+  && chown ${ROBOT_UID}:${ROBOT_GID} ${ROBOT_REPORTS_DIR} \
+  && chown ${ROBOT_UID}:${ROBOT_GID} ${ROBOT_WORK_DIR} \
+  && chmod ugo+w ${ROBOT_REPORTS_DIR} ${ROBOT_WORK_DIR}
+
 # Update system path
 ENV PATH=/opt/robotframework/bin:/opt/robotframework/drivers:$PATH
 
+# Set up a volume for the generated reports
+VOLUME ${ROBOT_REPORTS_DIR}
+
+USER ${ROBOT_UID}:${ROBOT_GID}
+
+# A dedicated work folder to allow for the creation of temporary files
+WORKDIR ${ROBOT_WORK_DIR}
+
 # Execute all robot tests
 CMD ["run-tests-in-virtual-screen.sh"]

README.md

@@ -92,6 +92,23 @@ This project includes the IMAP library which allows Robot Framework to connect t
 
 A suggestion to automate email testing is to run a [Mailcatcher instance in Docker which allows IMAP connections](https://github.com/estelora/docker-mailcatcher-imap). This will ensure emails are discarded once the tests have been run.
 
+## Security consideration
+
+By default, containers are implicitly run using `--user=1000:1000`, please remember to adjust that command-line setting accordingly, for example:
+
+    docker run \
+        --user=1001:1001 \
+        ppodgorsek/robot-framework:latest
+
+Remember that that UID/GID should be allowed to access the mounted volumes in order to read the test suites and to write the output.
+
+Additionally, it is possible to rely on user namespaces to further secure the execution. This is well described in the official container documentation:
+
+* Docker: [Introduction to User Namespaces in Docker Engine](https://success.docker.com/article/introduction-to-user-namespaces-in-docker-engine)
+* Podman: [Running rootless Podman as a non-root user](https://www.redhat.com/sysadmin/rootless-podman-makes-sense)
+
+This is a good security practice to make sure containers cannot perform unwanted changes on the host. In that sense, Podman is probably well ahead of Docker by not relying on a root daemon to run its containers.
+
 ## Continuous integration
 
 It is possible to run the project from within a Jenkins pipeline by relying on the shell command line directly: