Add conditional logic to drop permissions for unprivileged Docker

[jpiccari]

This change enables the container to run in unprivileged mode (without --privileged or additional capabilities) by making permission drops conditional:

• Changed users group GID from 1000 to 1001 to avoid conflicts with the app user's primary group (UID 1000)
• Only modify user/group IDs when PUID/PGID environment variables differ from the default value of 1000, avoiding unnecessary privilege requirements
• Skip su-exec entirely when running as the default user, since changing user context requires additional capabilities that unprivileged containers don't have

This allows the container to work in restricted environments like Kubernetes with security contexts or rootless Docker while maintaining backward compatibility for users who customize PUID/PGID.

Fixes #791

[jpiccari]

@Donkie this feels like a easy one to merge and would resolve an open issue. I know this project isn't your main focus right now, but let me know if there is anything further you need to get this one in.

[Donkie]

Ya this looks good, sorry for the long delay. Have you verified that this doesn't break any existing installs? I'm thinking about the id change of the group. The group of the volume mount that people have made will be different. Is the group id change to 1001 really necessary?

[jdh313]

Thanks for working on this! I was curious about the approach so I tested it locally. It looks like in the default case (PUID/PGID=1000), the condition evaluates to false, gosu gets skipped, and uvicorn ends up running as root instead of the app user. I think this might be a regression from the current behavior.

I'm also not sure if checking whether PUID/PGID differs from their defaults would solve what the linked issue is asking for, which is to run rootless. Would it be simpler to check if [ "$(id -u)" = "0" ] in the entrypoint to see if it's running as root, and use that to determine if gosu should be run?

[jpiccari]

@Donkie now I'm the one with the long reply, sorry about that. Yes I did regression test, it works normally and when run as other users. I also specifically tested in a k8s cluster that enforces non-root containers (as in the linked issue). All cases work fine. I have not done upgrade regression checks though.

The change to 1001 came during testing, I noticed some unexpected results when building the docker and/or when running the entrypoint script to update the app group ID. The UID will be the same, so I expect no issue but also didn't test it explicitly. Since the official image only supports the entrypoint run as root maybe we can add some change to the entrypoint (when run as root) to validate the folder ownership and permissions. I can pick that up if you can confirm the approach you think should be taken.

@jdh313 The behavior you describe seems expected to me. I expect users to provide a user/group to docker/k8s when running containers. Setting PUID/GID is meant only for adding the specified UID/GID to the app user/group (this requires root privileges or similar). I can't think of a reason someone would want to do this, but figured I'd keep it configurable in case someone had needs outside my expectations.