Running as root has many security disadvantages so it’s best avoided. Whenever possible, Minimus images default to a non-root user in keeping with the principle of least privilege. Minimus images will only default to root if there are constraints that require it. In contrast, many popular open source images default to root even when it isn’t required, so you may need to adjust to the change by changing directory permissions, etc.

​
Why default to an unprivileged user

To help protect against privilege abuse, Minimus images are built to default to an unprivileged user. Defaulting to an unprivileged user helps to limit what processes inside the container can do, preventing them from accessing sensitive files or performing privileged operations. Minimus images will only default to root when required due to technical constraints.

Running processes as the root user (UID 0) can lead to security concerns if an attacker gains control over the container. Once attackers gain root privileges inside the container they can potentially gain access to the host system as well. Therefore, running processes as unprivileged users is key to minimizing the attack surface on the container.

The Linux kernel on the host is responsible for managing the UID and GID space, with kernel-level syscalls determining requested privileges. For example, when a process attempts to write to a file, the UID and GID that created the process are examined by the kernel to determine if it has enough privileges to modify the file. Because the user privileges for all of the containers are controlled by a single kernel, you can’t have different privileges for the same UID/GID inside different containers.

​
Adapt to the default user in Minimus images

The Minimus Image Gallery lists the default user for each image directly in the UI under the details tab to help with the migration. If you prefer, you can also run docker inspect {image} to look up the default user directly in the CLI.

You can override the default user or change directory permissions as necessary.

​
Override the default user to run as root

Minimus images usually default to a non-privileged user, so you will need to explicitly run the image as root to perform tasks that require elevated privileges, such as debugging, especially when diagnosing issues related to permissions, file access, or network configurations.

You can use the --user root flag to run the container as root. For example, run an nginx container as root to bind it to port 80. (Running a service on a port below 1024 or binding to privileged ports requires elevated privileges.)

docker run --user root -p 80:80 {Minimus Nginx image}

​
Change directory permissions

When working with Minimus images, you’ll frequently want to bind a volume to persist data on the host. However, since the container isn’t running as root, you may run into permission issues. The simplest solution is to change the user permissions for the target host directory.

For example, the Elasticsearch process runs as UID 1000 by default. If you try to mount a volume, you need to change the permissions to give the target host directory read and write permissions (where /target/path represents your directory):

sudo chown -R 1000:1000 /target/path
sudo chmod -R 775 /target/path

  • 1000:1000 refers to the default UID (User ID) and GID (Group ID) for the Elasticsearch process.

  • The command sudo chown -R 1000:1000 /target/path gives the process ownership of the directory and its subdirectories. (The -r flag is for recursive).

  • The command sudo chmod -R 775 /target/path sets the permissions for the directory and its content, giving the Elasticsearch user and group read and write permissions.

Once the directory permissions are granted for the process, the directory can be mounted. In Elasticsearch, the run command might look like this:

docker run -it --name minimus-elasticsearch-example \
  -p 9200:9200 \
  -e "discovery.type=single-node" \
  -v /target/path:/usr/share/elasticsearch/data \
  {pull URL for latest Minimus Elasticsearch image}

This command will run the container and mount the target directory to the default Elasticsearch path to persist the data, so it’s not lost when the container exits.