To create a new user named 'foo' in a Docker container without requiring a password, you must use the
adduser command with the
--disabled-password flag within your Dockerfile. This approach ensures that automated processes can execute commands as the new user without interactive prompts or security risks associated with empty passwords.
Understanding the adduser Command
The
adduser utility is a high-level script provided by Debian-based Linux distributions, including Ubuntu and Alpine (via compatibility packages). Unlike
useradd, which is a lower-level binary,
adduser is designed to be more user-friendly and handles directory creation and default shell configuration automatically. When building a Docker image, you often need to switch from the root user to a non-root user for security best practices. Creating this user during the build phase is cleaner than doing it at runtime.
The core of the solution lies in passing the
--disabled-password argument. This tells the system not to set a password hash for the user. Instead, it marks the account as having no valid password, which effectively disables password-based login via SSH or console. However, it allows the user to log in if they have an authorized key or if the process is initiated locally by another user with sufficient privileges. This is ideal for service accounts inside containers where interactive login is rarely needed.
Constructing the Dockerfile
A standard Dockerfile begins with a base image. For this example, we assume a Debian or Ubuntu-based image. You should always run commands as the root user initially, as most containers start with root privileges. The steps involve installing necessary dependencies if they are missing, creating the user, and then switching context.
FROM ubuntu:latest
# Install adduser if not present in minimal images
RUN apt-get update && apt-get install -y adduser
# Create the user 'foo' with a home directory and disabled password
RUN adduser --disabled-password --gecos "" foo
# Switch to the new user for subsequent commands
USER foo
# Example: Create a directory owned by foo
RUN mkdir -p /home/foo/app && cd /home/foo/app
CMD ["bash"]
In this snippet, the
--gecos "" argument is crucial. It sets the GECOS field (typically used for full name, room number, etc.) to an empty string. Without this,
adduser might prompt for input during the build process, causing the Docker build to hang or fail because there is no TTY attached. The
USER foo directive changes the effective user ID for all following instructions in the Dockerfile. This ensures that any files created subsequently are owned by 'foo', not root.
Security Implications
Running applications as a non-root user is a fundamental security practice. If an attacker exploits a vulnerability in your application, they gain access only to the permissions granted to 'foo'. They cannot modify system-wide configurations or install malware easily. By using
--disabled-password, you ensure that even if the container is compromised, the attacker cannot escalate privileges via password guessing attacks on the 'foo' account.
However, note that disabling the password does not mean the user has no identity. The user still exists in
/etc/passwd. If you need to restrict shell access further, you can set the shell to
/usr/sbin/nologin or
/bin/false. But for most containerized applications that need to write logs or temporary files, a standard shell like
/bin/bash or
/bin/sh is required.
Verifying the User Creation
After building the image, you can verify that the user was created correctly by running a container interactively. Use the
docker run command with the
-it flags to allocate a pseudo-TTY.
docker build -t my-app .
docker run -it my-app id
The output should show the user ID and group ID of 'foo'. If you want to check the password status, you can inspect
/etc/shadow inside the container, but remember that reading shadow files requires root privileges. A simpler check is to try logging in via SSH; it should reject password attempts while allowing key-based authentication if configured.
Related Resources
For more complex setups involving multiple services, consider how to
Allow Arguments to be Passed to Multiple Services in Docker. Additionally, understanding how to manage local resources can help with
Prevent Using Remote Image in Docker: Dockerfile Base Image Command.
Frequently Asked Questions
Why does adduser prompt for information?
By default, adduser asks for user details like the full name. Using the
--gecos "" flag suppresses these prompts by setting all fields to empty strings, which is essential for non-interactive Docker builds.
Can I use useradd instead of adduser?
Yes,
useradd is available in many base images and does not require installation. However, it does not create a home directory by default unless you specify
-m, and it lacks some of the friendly defaults that adduser provides.
Is it safe to leave the password disabled?
Yes, for containerized applications, leaving the password disabled is safer than setting a weak password. It prevents brute-force attacks while allowing programmatic access through other means like keys or sudo privileges.
How do I give foo sudo privileges?
You can add 'foo' to the sudo group after creation using
RUN usermod -aG sudo foo. Ensure that sudo is installed in your image before attempting this modification.
What happens if I forget USER foo?
If you omit the
USER foo directive, all subsequent commands will run as root. This violates security best practices and may cause permission errors if your application expects to run as a specific user.