Hi,

I'm trying to understand the role of the user created on the host for docker (this is ultimately just an example, but I'm guessing the principle should be the same everywhere).

When I activate docker's user name mapping ("userns-remap": "default"), so that the containers run in a different username space, docker makes use by default of a user called dockremap.
The mapping I can see in /etc/subuid:
The processes running as root inside the container are shown using the 558752 UID:
Likewise docker creates a special extra folder for all containers/volumes etc. when running with this special user, and the effective permissions correspond to the mapped UID (the big number):
Which again is to be expected, 'cause that's the effective UID that the processes are using to access the resources inside that folder.
But I still don't understand how the actual user (i.e. its 111 UID) on the hostname is being used.

Thanks in advance!

This feature is not really docker related, just used by docker (amongst others).

probably this helps: https://www.man7.org/linux/man-pages...espaces.7.html
(and this: https://www.man7.org/linux/man-pages...wuidmap.1.html)

Technically the usage of a fake "dockremap" user is a odd quirk of Docker and is a slight misuse of the /etc/sub[ug]id files. The idea behind /etc/sub[ug]id files is that they allow you to specify which IDs are available for users to use for user namespace purposes (using the new[ug]idmap set-uid helper binaries). Since Docker is a privileged program (running as root) it doesn't need any such entry, but Docker supports it so that admins can specify separate ranges for Docker and other users. LXD can be configured in a similar way, but they use "root" as the user (which is slightly more correct semantically, but means you cannot specify separate a separate range just for LXD if another program wants to use the root users' reserved mappings).

Can you please expand on that a little bit? Your post is very helpful, but I haven't understood the whole of it.
How are separate ranges actually achieved by docker if they create this fake user? And how would the LXD be limited when they use 'root'?

Only one line is used from /etc/subuid, based on the username. You can set this user in the config of docker daemon. It can be either a valid user or this dockremap "virtual" user (default). This username (or userid) is not used, only once when the daemon started. dockerd reads the line belongs to this name (from etc/subuid).

Docker doesn't use the fake user (Docker runs as root), it's just an odd method of configuration. Neither LXD nor Docker are "limited" in a strict sense (they both run as root after all, so they can map any users they want into a user namespace). However, the idea of /etc/sub[ug]id is that you have a single place on the system where you allocate IDs for use in user namespaces (similar to /etc/passwd or /etc/group).

Privileged runtimes use the configuration of those files when deciding which range of IDs to map inside user namespaces (for Docker, the container gets the entire range while LXD lets you map independent ranges for each container to stop cross-container attacks). This means if an admin configures both LXD and Docker on a single system, they can allocate separate ranges for each runtime (meaning that the containers by the different runtimes won't use the same IDs -- which blocks some cross-container attacks). Again, Docker and LXD aren't forced to obey this, it's just a configuration option (they both run as root and can map any users they want to -- and LXD even lets you configure this dynamically per-container).

However, the intended use of /etc/sub[ug]id is that it lists which IDs unprivileged users are allowed to map into their containers. The set-uid helpers new[ug]idmap then allow those unprivileged users to map those IDs when they are creating containers (this is needed for the same reason that newgrp is needed).

1 members found this post helpful.

That is true. Docker use dockerd to run containers (docker itself is just a dumb client to send requests to dockerd), so the user who initiated it is [more or less] irrelevant. That is a "big" problem with docker, the daemon runs as root and actually has no any idea about the original user. Probably it will be changed in the future, but actually the only restriction is that the user should belong to the group docker (and the user id is lost).

1 members found this post helpful.

Thank you both for the answer, it's slowly becoming clearer.

One more thing related to /etc/subuid. pan64 says that only line can be used from /etc/subuid, but that doesn't seem to be the case with docker. I think that's exactly how you set several ranges different ranges, if I'm not mistaken.

pan64 was mistaken (probably since they hadn't seen an /etc/sub[ug]id file with more than one range for a user before since it's a little bit of an unusual setup). Docker appends all the ranges specified in /etc/sub[ug]id and maps them all, but that's just how they decided to implement its usage of /etc/sub[ug]id -- though I think LXD does the same thing.

That was my fault. Only one user will be used, which is specified in daemon.json, that is the correct statement. Sorry.