[BUG]: Large UIDs on alpine images cause initialize job to fail

[tiehfood]

What happened?

My user on the host running the agent has a very large UID. This causes problems with the adduser command on alpine images:

exit code: `1`; command output: `adduser: number 669624785 is not in 0..256000 range`

The suggested solution is to use useradd instead, as this could handle large UIDs.
I think this was also the intention, as the shadow package including this command is listed as dependency for alpine images in the Microsoft tutorial. But this command is never used (

azure-pipelines-agent/src/Agent.Worker/ContainerOperationProvider.cs

Line 626 in c313e3e

if (isAlpineBasedImage)

)
Is there any reason why adduser is used instead?

Why at all is there a user created with the same UID than the local one? Doesn't this break images, which require a specific user defined in the Dockerfile or even need to be executed as root?

Versions

latest / RHLE 8

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

No response

Version controll system

No response

Relevant log output

No response

[ismayilov-ismayil]

Hi @tiehfood, thanks for reporting! We are working on more prioritized issues at the moment, but will get back to this one soon.

[tiehfood]

This is quiet important for us. We evaluate migrating a project from GitLab to Azure DevOps.

[github-actions]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[DenisRumyantsev]

@tiehfood thanks for reporting this. The fix is implemented and will be available in the following agent release. If the shadow package is installed in the container, it will be used by default. If the shadow package is not installed in the container, commands default for Alpine (adduser, addgroup) will be used. If user ID is outside the range of the adduser command and the shadow package is not installed in the container, there will be an attempt to install the shadow package and use it.

Why at all is there a user created with the same UID than the local one?

There were some issues that require to have same user ID and group ID as on the host on which the agent is running.
An example — #3362

Now it is the default behavior that we cannot change. If you want, you can create a feature request regarding this question and describe your suggestion in more detail. Probably it can be implemented as boolean inputs (additional for the container input) like defaultUser: true or root: true.