Use a lower UID/GID than 65532

[akostadinov]

Which image/versions are related to this issue/feature request?

static/all

Issue/Feature description

When running rootless docker or podman, one has to create subuid reserved ranges for each user that would use docker or podman rootless.

It is not practical to reserve huge number of uids when in container usually only one non-root user is used. So I think it is much more sensible to have the default user to be 1000 or 1001 instead of 65532. Given that a very high UID doesn't provide practical benefits.

[tuananh]

i would like to chime in a bit here.

When running on Openshift, it's automatically change to a very high arbitrary uid like 3912388232. I dont remember exactly now.

[akostadinov]

@tuananh , this is true, OpenShift assigns a random UID to unprivileged containers. This is during runtime though. For OpenShift it doesn't matter what file permissions are. I don't think it uses the user namespaces (at least not yet).

OpenShift also sets process gid to 0. So to make images on OpenShift work by default in unprivileged mode, one has to make directories that are supposed to be writable by the container process to gid 0 and be group writable.

But this is a separate topic I think. Although related. It would be nice to have the nonroot home directory with git 0 and group writable - yes :)

[tuananh]

yeah i just want to put everything on the table so we can decide where to go next.

OpenShift also sets process gid to 0. So to make images on OpenShift work by default in unprivileged mode, one has to make directories that are supposed to be writable by the container process to gid 0 and be group writable.

that's right

[amouat]

A high uid does have some benefits, in particular it is much less likely to map onto an actual host user. In other words, in the event of a container breakout, the attacker should not find themselves in a privileged account.

[akostadinov]

@amouat , that's the point of user namespaces, that you can be root in container but something insignificant on the host. To run without user namespaces, one has to apply caution anyway.

If you run multiple containers without user namespaces and they are based on the same "safe" defaults, then you will end-up with all containers running the same uid. Just an innocent example.

Although same applies if you use namespaces but run containers as the same host user. But that is the point of the issue - that a lot of uids have to be reserved just to run a single container.

[amouat]

Thanks @akostadinov. The thing is not everyone can run with user namespaces on e.g. because of issues with volumes. With that in mind, I'm not sure what to do here. What UID would you like to see used? I think 1000 and 1001 are bad as they will map to existing users for non-user namespaced workloads.

[akostadinov]

I've run with volumes, yes, they need selinux and maybe some other permissions adjusted. But then, if you run with a random UID, that shouldn't be much different. Actually I'm not sure one can run docker/podman rootless without user namespaces.

If 1000 and 1001+ are no go, then maybe it makes sense to set it to 999. Given user nobody is 99 by default, then nonroot being 999 has some consistency in it.

My concern is that these high UIDs may mostly give a false sense of security to unwary users than actually help. While any layer with files in the high UID range will fail without allocated enough UIDs. Even if later layers remove those.

On the other hand this also might be not a significant issue provided UIDs are 32bit. One can allocate some 65k 16bit ranges. But still it seems to me rather wasteful. So unless that is a really huge server, probably one will not run out of uid ranges.

[patflynn]

Assigning to @kaniini. This requires some more analysis and design and won't likely be started until Q2.