common-utils fails when existing user’s primary group name differs from username (e.g. users:100)

[e-s-a-i]

https://github.com/devcontainers/features/blob/10b6e7150db6b9d5adb76fb80b5cd4455ec03e82/src/common-utils/main.sh#L415C1-L415C25

When building a Dev Container on top of a base image that already defines a non-root user whose primary group name differs from the username, the common-utils feature fails with a chown error during installation. This happens because the feature hard-codes group_name="${USERNAME}" and later runs chown ${USERNAME}:${USERNAME}, even if the user’s primary group is different.

Example context:
In my Dockerfile I pre-create the development user before features run:

ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=100
RUN groupadd --gid $USER_GID users \
    && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME

This results in vscode:users, where users (GID 100) already exists in the base image.
When common-utils runs, it tries to ensure ownership with chown vscode:vscode, producing:

chown: invalid group: 'vscode:vscode'
ERROR: Feature "Common Utilities" failed to install!

Root cause:
install.sh assumes that ${USERNAME} and the user’s primary group name are identical. When a user already exists with a differing group name, the feature tries to create or modify a conflicting group and later chowns to a non-existent vscode group.

Expected behavior:
If the user already exists, the script should:

• Detect the actual primary group via id -gn "$USERNAME", and
• Use that value for group_name and subsequent chown operations instead of assuming ${USERNAME}.

Proposed fix:
Replace the current unconditional group_name="${USERNAME}" assignment with something like:

group_name="$(id -gn "$USERNAME" 2>/dev/null || echo "$USERNAME")"

and skip groupadd/groupmod if that group already exists.

This would make the feature compatible with base images that already define non-root users.

[e-s-a-i]

I took some time to try to explain this issue better.

The offending command sequence is this:

...
group_name="${USERNAME}"
if id -u ${USERNAME} > /dev/null 2>&1; then
    # User exists, update if needed
    if [ "${USER_GID}" != "automatic" ] && [ "$USER_GID" != "$(id -g $USERNAME)" ]; then
        group_name="$(id -gn $USERNAME)"
        groupmod --gid $USER_GID ${group_name}
        usermod --gid $USER_GID $USERNAME
    fi
...

The second if conditionals both check the value of USER_GID which in my case equals the output of the command "$(id -g $USERNAME)" in the second conditional.

So the line group_name="$(id -gn $USERNAME)" is never run.

The previously set group_name="${USERNAME}" is then used later in the code to chown the user directory and other files.

So if I do everything correct, the code will just skip setting the variable to it's actual value.
Resulting in the script failing later.

Two workarounds for now:

1. Setting the group name to equal the user name, which in my case is not the desirable configuration.
2. Let the script misconfigure the user, and set things right later with a postStartCommand.

I intend to use multiple users to run different tools, each of which should have read permissions granted by the group.