What does the 999 on the docker mean:
Almost nothing. It's just an ID assigned to that group.
Though the fact that it's less than 1000 indicates it's a "system" group that was created for a package (as opposed to a group that was created by you), but while that sometimes makes a technical difference for users (UIDs), for groups it's purely organizational.
When you use groupadd
(or when the OS package manager uses it after installing a package), newly created "system" groups get GIDs starting from 999 down, while non-system groups get GIDs starting from 1000 up. In your case, 999 happens to have been the first free GID in the system range.
what does all the numbers that appear when running the id command mean anyway?
Also nothing, they're just unique IDs assigned to each user account and each group. Internally the OS works with integer UID/GIDs as they're somewhat more convenient to store than variable-length names. (The mapping of IDs to names is usually stored in /etc/passwd
and /etc/shadow
.)
why can I simply become root by running
Linux containers (the kind that Docker creates) originally did not have any UID separation at all: UID 0 (root) of every container was the same as UID 0 on the host. Although UID isolation later became available, Docker's architecture predates that.
So technically, with Docker, root in a container never stopped being root on the host – it's just that the host files were out of reach from the container; there were no valid paths that could go outside the directory that was designated as the container's own /
. The only paths a container can access are those that Docker "binds" into the container.
But if you specifically ask Docker to bind some part of the host filesystem, then the container becomes able to access that; and if you ask Docker to bind the entire host /
, the container becomes able to access all of it.
(What makes it even easier is that due to lack of UID separation, only root is able to set up a container in the first place – so the docker
command has to work by talking to a dockerd daemon that always runs as root. This means that any user who's allowed to access dockerd can request it do things with root privileges.)
More modern container runtimes do isolate users as well (using the recently added "user namespaces"); e.g. with systemd-nspawn, container UIDs no longer match host UIDs.