-
Notifications
You must be signed in to change notification settings - Fork 0
Description
We generally want to run containers as unprivileged users, but we don't necessarily know in advance which user and even if we do, hardcoding specific user IDs into images introduces unnecessary coupling between components.
The only real downside to running as an unknown user is aesthetic because every time you start a shell in the container you get this nonsense:
groups: cannot find name for group ID 10001
I have no name!@089c6a253de7:/$
We sometimes deal with this by mounting in /etc/passwd and /etc/group e.g. here:
- /etc/group:/etc/group:ro
- /etc/passwd:/etc/passwd:roBut this feels quite nuclear as a solution, and also relies on the container being invoked in a certain way rather than being part of the image's own configuration.
A simpler solution would be to customise /etc/bash.bashrc. The I have no name! user is a consequence of the PS1 prompt set by this script:
# set a fancy prompt (non-color, overwrite the one in /etc/profile)
# but only if not SUDOing and have SUDO_PS1 set; then assume smart user.
if ! [ -n "${SUDO_USER}" -a -n "${SUDO_PS1}" ]; then
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fiAnd the cannot find name from group error comes from a call to groups in a sudo hint check:
# sudo hint
if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] ; then
case " $(groups) " in *\ admin\ *|*\ sudo\ *)
if [ -x /usr/bin/sudo ]; then
cat <<-EOF
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
EOF
fi
esac
fiWe can disable the sudo hint by creating an empty file at /.hushlogin but I think there would be another benefit to providing our own script here and that is that we can get it to source additional files from /etc/bash_completion.d/ (there's code to do something like this in the original script but it's commented out).
That means that downstream images can add additional files here and know that they will be sourced on starting a shell regardless of the user.
For a specific use case for this, and further discussion see:
opensafely-core/job-runner#1034 (comment)