Docker produces directories owned by undefined GIDs/UIDs

Solution In Progress - Updated -

Environment

  • OpenShift Container Platform
  • Docker Container Runtime

Issue

  • When Docker container runtime is in use, its directories for containers and images are owned by root, but have seemingly erratic GIDs such as 1000270000, or 50, or GIDs otherwise undefined in /etc/group.
  • A security application or scan has alerted me that it isn't safe to have undefined groups floating around my system, and I need to know if this is normal behavior for Docker, and safe to leave as-is.

Resolution

  • There is a difference between "deterministic" and "non-deterministic" groups, i.e. groups who are explicitly defined by the kernel, and groups that are not.
  • As discussed in a previous solution, Docker and OpenShift will create user accounts such as the following, with non-deterministic GIDs and/or UIDs:
dockerroot:x:271:271:Docker User:/var/lib/docker:/sbin/nologin
etcd:x:270:993:etcd user:/var/lib/etcd:/sbin/nologin
hacluster:x:189:189:cluster user:/home/hacluster:/sbin/nologin
  • Docker processes will be owned root:root by default, and use randomly generated UIDs and GIDs, and the parent system will see these values.
  • While these values aren't defined explicitly in the /etc/group file on the parent system, this is normal behavior, and shouldn't be considered a security concern or vulnerability.

Root Cause

Since Docker runs on top of a single linux kernel (we can think about it as a hypervisor of sorts for the container runtime) but also needs to run containers as root processes, it will assign different UIDs and GIDs to its containers (processes) than the system root UIDs and GIDs to avoid conflict between containers. Different "root" accounts, all handled by the same kernel and user/group system must be able to run side-by-side, and if they all had the same UID and GID they wouldn't be able to do so, as to the parent system this would have the appearance of the system's "root" account being logged in many times simultaneously. If we think of this phenomenon as the relationship between a hypervisor and virtual machine, we can think of a container as being a transparent process that requires its own unique "root" identity for getting things done, while a hypervisor/virt keeps that relationship completely isolated as each virtual machine runs its own kernel and in turn its own user/group management system.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.