Search code examples
dockerdockerfile

Does adding a user without a password to a Docker container pose a security issue?

Does adding a user without a password to a Docker container pose a security issue? I added the following lines to the php Dockerfile to fix the permission issue of files:

RUN addgroup -g ${gid} --system laravel
RUN adduser -G laravel --system -D -s /bin/sh -u ${uid} laravel
RUN sed -i "s/user = www-data/user = laravel/g" /usr/local/etc/php-fpm.d/www.conf
RUN sed -i "s/group = www-data/group = laravel/g" /usr/local/etc/php-fpm.d/www.conf

It creates a user with the given uid and gid, however, no password is set for the user. I would like to know if such a thing may pose a security issue to the container.

Thanks in advance.

Solution

  • The setup you show is extremely routine and I wouldn't worry about it.

    At a Docker-container level, the container only runs the main process identified by the ENTRYPOINT and CMD directives, as overridden by runtime. It doesn't run a login service, getty(8), or anything else that might accept or verify a password. The docker run -u option will let the operator pick an arbitrary user to use, and Docker won't do any checking on whether that user is "allowed" (or, if its a numeric user ID, if it's even listed in /etc/passwd).

    At a Unix level, an account can have a disabled password. The adduser(8) documentation for the -p, --password option notes

    The default is to disable the password.

    so not setting a password is a little more secure.

    The Stack Overflow questions that I see that do try to use passwd(1) have some major security issues in themselves. The password is almost always very guessable (I frequently see password, without even a 0). It's written down in plain text in the Dockerfile, so it can be found in source control. It's also recorded in the image metadata, so docker history also shows it to anyone who has the image.

    I might remove the -u (explicitly set uid) and -s (shell) options. When you use this user later on, do not chown(1) every file in your image to that user, only a specific directory of files that actually need to be written. But if you do that, setting up a non-root user this way is good practice.