image-spec
image-spec copied to clipboard
opencontainers
Should containers inherits the group/gid from the image configuration?
From https://github.com/opencontainers/image-spec/blob/master/config.md#properties
User string, OPTIONAL
The username or UID which is a platform-specific structure that allows specific control over which user
the process run as. This acts as a default value to use when the value is not specified when creating a
container. For Linux based systems, all of the following are valid: user, uid, user:group, uid:gid,
uid:group, user:gid. If group/gid is not specified, the default group and supplementary groups of the
given user/uid in /etc/passwd from the container are applied.
the scenario is simple, what happens in the following case:
User 1000:100
and the container runtime just specifies to run the container as user 3000? Should it inherit the group from the image configuration? it shoiuld run the container as 3000:100. Right now, in docker for instance, that's not the case, it'll end up running 3000:0 (0 being a default).
/cc @simo5 @vbatts xref https://github.com/openshift/origin/issues/8618
If you specify intentionally a different user, it doesn't make sense to me to stick with the group defined in the image. It should be the deployer care to also specify a group to use, or the system should be free to apply a default group.
If nothing is specified both user and group can be sourced from the image. Ideally through use of namespaces the latter is what normally happens while the platform maps any [ug]id to custom values under the hood and the container is none the wiser.
The reason that this isn't the case in Docker is because Docker implements the configuration stuff as though --user overwrites the User parameter in the image configuration (so the conversion code doesn't know what the old user spec used to be). The problem with the current conversion documentation is that (because different runtimes do things differently) either approach is technically valid.
My personal view is that it depends on the UX (from the principle of least surprise), though I also don't like that Docker defaults a lot of things to root -- this is something we shouldn't recommend in general IMHO. Defaulting to the gid in the image specification is the least surprising option (unless of course the user specified an /etc/passwd username -- in which case the groups should be the same as in /etc/passwd and /etc/groups).
oh no. This is no good. How was the default gid 0?!
So:
A) if there is a uid:gid provided in the config, then the runtime overrides just the uid, then the gid ought to inherit.
B) if only a uid is provided [and is not 0], by config or runtime, then the gid ought to default to something like nobody
@vbatts Currently the OCI spec doesn't default to 0 -- it defaults to whatever is in /etc/passwd and /etc/groups for the user (or uid) specified. To be fair, doing it for uid is a bit dodgy (you can have more than one user for each UID) but I think the current semantics are not that bad.