map uid/guid to different ids

[bsutton]

My understanding is that when postfix starts it uses a couple of user/group that are mapping to uid 101/102.

My problem is that I need this group to read the config folder from the host.

On the host the uid 101 maps to is something like system-journal, this means that on the host I have to give the postfix config file are rather confusing looking permission.

Is there some what to force the postfix container to use alternate uid/gids so that I can map them to unused uid/gids on the host.
I can then create a postfix user on the host with the same uid as the containers postfix user and my host permissions now look sensible.

[bsutton]

I note that your documentation states:

While I cannot guarantee IDs (they are auto-generated by package manages), they tend to be fairly consistent across specific distribution. Please be aware of this if you are switching images from Alpine to Debian to Ubuntu or back.

I don't believe this is correct because if you create the users/groups before running the package manager they should use the existing uid/guid.

I play a similar game for the maria db container:

# add our user and group first to make sure their IDs get assigned consistently

RUN groupadd -g 2002 -r mysql && useradd -u 2002 -r -g mysql mysql --home-dir /var/lib/mysql

So if the container where to take a couple of env vars with the desired uid/gid then I think that would provide a solution.

[bokysan]

HI Brett,

Thank you for your comment. Unfortunately, (system) users are assigned to apps when the container is built, not when it's run.

So implementing ENV vars would do nothing more than fail to start the container if you were to change them.

If you do have any good ideas, I'm open to pull requests.

B

[bsutton]

So plan b: assign the users to a higher UID that have a lower chance of causing a collision. e.g. 20001

…

On Thu, Aug 15, 2024 at 2:38 PM Boky ***@***.***> wrote: HI Brett, Thank you for your comment. Unfortunately, (system) users are assigned to apps when the container is built, not when it's run. So implementing ENV vars would do nothing more than fail to start the container if you were to change them. If you do have any good ideas, I'm open to pull requests. B — Reply to this email directly, view it on GitHub <#210 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OAYDE3NS7YRIVPM2DLZRQWEDAVCNFSM6AAAAABMRKKCTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJQGU4DAMBVGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bokysan]

@bsutton While assigning higher IDs most likely will cause less collision, we still do not eliminate it.

Another issue is changing the IDs now would cause a lot of headache to existing users, as their images would suddenly stop working.

I certainly do not have a good way out of this. Any other ideas?

[bsutton]

Perhaps a half way mark. Change the docker file so the build phase takes the ID's from an env var - in this way people like me could easily grab the build script and create a custom image. Add some doco on how to pass the ID's to the build phase. No breakage for existing users but a nice solution for everyone else.

…

On Sun, Sep 15, 2024 at 5:43 PM Boky ***@***.***> wrote: @bsutton <https://github.com/bsutton> While assigning higher IDs most likely will cause less collision, we still do not eliminate it. Another issue is changing the IDs now would cause a lot of headache to existing users, as their images would suddenly stop working. I certainly do not have a good way out of this. Any other ideas? — Reply to this email directly, view it on GitHub <#210 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OG7FQVRR3T3L7ZVEDTZWU3AVAVCNFSM6AAAAABMRKKCTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJRGQ2DAMBUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bokysan]

I can live with that. Passing IDs at a build time is done in Dockerfile via ARG instruction and then via --build-arg when running docker build.

What would need to be done here:

1. Add ARG instruction to Dockerfile
2. Change the build script to take it into account if set
3. Ensure that it works on all flavours (Debian / Ubuntu / Alpine)
4. Ensure that if not set, the defaults persist.
5. Update documentation to explain how to build this yourself with different IDs.

Frankly, I don't see this as a high-priority feature, but if you would like to take a crack at it, I'd be more than happy to accept a PR.