Use same user and group in Docker

[feliperetamar]

I'm using the docker hub image and an external volume

when updating docker image some times the user and group of the image has changed and container doen't work. I have to chown the volume data with the new values

Can you use the same UID:GID between versions? or add instructions about the use of this docker hub image

Thank you

[evilaliv3]

Thank you for reporting this @luisfeser

We are currently not specifying the UID:GID enabling debian to assign the first on setup and we were considering this to remain constant in the context of debian but apparently something changed with the trixie release.

By any chance did you already look into the topic and do you have suggestions?

In the past with @rglauco we evaluated using the number 999 that is is a good candidate, used for example by mongodb and postgres

[evilaliv3]

I actually rechecked on the last releases:

• The last running with Debian bookworm has uid:gid 103
• The current running on Debian trixies has still uid:gid 103

Maybe @luisfeser you were running a very very old release?

since every of our images since recent times is using 103, i think we could do the following addition to the Dockerfile:
RUN groupadd -r globaleaks --gid=103 && useradd -r -d /var/globaleaks -g globaleaks --uid=103 globaleaks

This will offer the following guarantees:

• the globaleaks user will get 103 if it was available before installation (that should be always the case on a debian-slim)
• in the future in case this wont be a possibility we will discover the situation due to the first failure; and at that time we will know we really need to vary he number.

What do you think?

\cc @rglauco

[feliperetamar]

Hello, @evilaliv3

My point of view

On the first point, I guess it’s inevitable that in some systems the UID:GID you choose will collide with one from the host. But that should be very occasional.
If Docker runs as root, we know it can mount any directory from the host into the container and the UID doesn’t really matter. And when running in rootless mode, higher UIDs are assigned anyway.
What I mean is that the UID number is mostly about aesthetics and avoiding common IDs used in regular systems.
From what I’ve seen, Alpine uses nobody (UID 65534) and sometimes nonroot (UID 65532).
In muy previous post i said UID => 300 but it's better => 3000
Maybe the Docker --user option will work, but i don't sure because of security in Globaleaks image. I doesn't tried.

On the second point, it has already happened once. I know what the solution is, and if it happens again but is well documented in the changelog and the fix is definitive, that’s acceptable.

Thank you

[evilaliv3]

@luisfeser : we just released a 5.0.83 that uses 1000:1000.
do you mind checking if it works for you?

thank you!

[feliperetamar]

Thank you, but I think 1000 is very common in production systems. I would avoid using it.

I'd prefer any number higher of 3000, or maybe 999 like you said previously

Could you think about?

[evilaliv3]

Thank you @luisfeser .

Would you please clarify which is your concern @luisfeser? I don't really have particular concern since I think the best recommendation here is to use volumes and not host paths, and avoid to mount volumes on the host.
Why would one mix host and containers by mounting the volume directly on the host? If I'm not wrong many unexpected manipulations by the host system on the container filesystem might happen if one proceededs this way.

I'm ok for changing it, maybe with an uncommon number like 1337. Maybe someone will blame for the many changes, but if this makes you happy we could do it.

[rglauco]

@luisfeser you can use docker rootless to avoid any uid:gid mixups. Globaleaks runs very well on it.

[evilaliv3]

Since we are running rootless, what about enforcing 1000?

This for sure won't be present in the Debian base image and it is quite standard to give this to the first non root user.

@rglauco

[rglauco]

After our nightly docker tests with user 1000 i tried v5.0.83 on:

1. podman 5.4.0 Rocky Linux 9.6
2. kubernetes v1.29 securityContext allowPrivilegeEscalation: false and runAsNonRoot: true

it works on both