feat: run container as non root user

[rwaffen]

No description provided.

[rwaffen]

hmm, damn, in my local tests this worked :(

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[defnull]

Just an idea: How about an entrypoint script that dynamically creates a user with the same UID and GID as the owner of the /repo directory, and then drops privileges to that user? That way, all files created or edited by the in-container user will have the same owner as the host directory mounted into the container. I do that in some of my development containers to avoid ending up with files owned by root or some arbitrary UID.

Here is a quick example from one of my dev containers:

#!/bin/bash
export DEVUID=$(stat -c '%u' /repo/)
export DEVGID=$(stat -c '%g' /repo/)
export DEVUSER=voxbox$DEVUID
export DEVGROUP=voxbox$DEVGID
addgroup -S -g $DEVGID $DEVGROUP &>/dev/null
adduser -S -u $DEVUID -G $DEVGROUP $DEVUSER  &>/dev/null

exec runuser -u $DEVUSER -g $DEVGROUP -- "$@"

[rwaffen]

that could be a thing! we can try this

[rwaffen]

on my mac i dont have to add --userns=keep-id, on my linux workstation i do.... not sure whats the right way. noz sure how ci behaves 🤔

[rwaffen]

@defnull do you have any thoughts on this? Your solution is also okay. But when you run it like this and the group might already exist alpine ash will break. And we shouldn’t be needing cloning a user. The runtime should/could map this for us 🤔

[defnull]

Hm. Creating a fixed non-root user with UID=1000 should work fine in most single-user developer environments, but will break with permission errors if the host user (and thus the /repo folder) has a different owner, which can happen in a multi-user environment or situations where you have a dedicated development user to run build/test tasks. This would be a breaking change I guess, and using the container for such users would be really annoying.

I see two solutions:

• Keep it the way as it is and execute the commands as root within the container by default, but allow and teach users to run the container with their own user ID if needed. Either with --userns=keep-id or --user=$(id -u). This means that all features of the container should work as a non-root user that may or may not actually exist. Calling --user=1234 will run the process as that user, but the user has no username and no home folder. That may cause problems.

• Guess the correct user from the /repo folder or let users pass in the desired IDs as an environment variable and write a robust entrypoint that creates a matching user on demand, and can also deal with ID conflicts.

I can imagine that my example entrypoint breaks if the folder is owned by root (user or group) or a system user or group (<1000). In those cases, the addgroup/adduser commands may fail silently, but the runuser command would then complain that it cannot find the target user. Any IDs >=1000 should be fine because they do not exist in the container, and won't cause name-conflicts when created because their names contain their id.

[rwaffen]

okay, thx for the input. will try something tomorrow on the train. :D