Bugfix: change default git user to 1010:1010 and make git user more configurable

[stuartbirrell]

Bugfix for: #23632

There are several issues with the hardcoded values in the existing Dockerfiles (1000:1000).

This change adds GIT_GID and GIT_UID env vars to the Dockerfile. This allows the builder to optionally set custom user and group IDs for the git user.

If no values are supplied, then it will default to a new UID and GID of "1010" - which will avoid any conflicts with the default user(1000:1000) on some systems.

I also made amendments to the docker installation documentation(.en and .cn) to reflect the changes.

[techknowlogick]

Thank you for your PR. I'm worried that this might be a breaking change for users who have their files already owned by the current IDs. Are you able to suggest a path forward to ensure that existing users won't need to run manual tasks prior to upgrading?

[jmptbl]

Thank you for your PR. I'm worried that this might be a breaking change for users who have their files already owned by the current IDs. Are you able to suggest a path forward to ensure that existing users won't need to run manual tasks prior to upgrading?

Perhaps docker-setup.sh can perform an ownership check of Gitea's data files. If ownership is incorrect, fail in a similar way as when the RUN_USER check fails, with a description of how to fix the issue. Alternatively it might be possible to ship a setuid root binary that resets ownership automatically, but that should probably be included in the image for only a limited number of releases.

Unfortunately this is not an easy fix. Bullets have to be bitten, or the Docker image will remain fundamentally flawed.

I'm not sure 1010:1010 is a great choice either. Generate a random number between 5000 and 20000, and use that. The idea is to pick a UID and GID that is unlikely to clash with an existing user account on the host server. Every Linux distro I know of allocates UIDs and GIDs starting from 1000.

[lafriks]

I don't think this is a good solution, I don't see how clash with host UID/gid affects anything, containers are namespaced and UID does not really affect much, as for risk host user accessing volume data, this should really be controlled by parent directory rights to prevent that

[eeyrjmr]

I agree. The point of containers is to isolate processes and users and this is why sub UIDs exist.

Yes there is a way to map a host user to a guest user but that is usually to hack around another wider system configuration shortcoming.
Moving gitea uid from 1000 to 1010 doesn't solve this system problem, just moves it.

THUS the question has to be asked... Why is --user used to launch the container to then be hit with this uid clash.

NOTE making the uid/gid configurable isn't a bad thing but also neither is the assumption that a container dedicated to an isolated process wouldn be the only user and thus starting at 1000, as per convention, is valid

[jmptbl]

@lafriks @eeyrjmr While Docker does support namespaced UIDs and sub UIDs, it is not enabled by default. UID x in a container is the same UID x in the host. Anyway, enabling user namespaces would only complicate matters in this case.

The issue here is a combination of SSH pass-through and IsRunUserMatchCurrentUser/mustCurrentRunUserMatch.

It is desirable to pass SSH connections through from the host to the container using a simple process execution in the container environment. For that to work, Gitea in the container needs to be running on a UID that the host is able to allocate to a dedicated SSH user account. If Gitea is running on UID 1000, that's very likely to clash with a pre-existing user account on the host.

Considering how the container needs to interact with the host in this case, it is reasonable to allocate a unique UID to the container, just like daemons running in the host are commonly allocated unique UIDs as well.

That said, half of the problem is Gitea's IsRunUserMatchCurrentUser function. It is easy to run a Docker image on a UID different from what was declared in the Dockerfile, but this function causes Gitea to fail at startup if the UID doesn't match the RUN_USER /etc/passwd entry that's baked into the Docker image. I see this function is bypassed if the internal SSH server is enabled, so I gather this function exists only as some kind of safety net to catch common configuration errors made by the admin.

If the default UID must remain 1000, the questions to ask then are:

1. Why does Gitea need IsRunUserMatchCurrentUser? I don't think its needed, so there should be a configuration option to bypass this function, irrespective of the internal SSH server state, and arguably it should default to enabled in the rootless Docker image.
2. Following on, why does the rootless Docker image then need passwd and group entries? I think they become superfluous if IsRunUserMatchCurrentUser is bypassed.