UID/GID mapping in application containers

Well known problem with application containers is UID/GID mapping between the container and the shared folder on the host.

Some years ago we have used the following trick, in the container entry script:

## update UID and GID as per ownership of mounted dir.
appdata_dir="/opt/appdata"
if mountpoint "${appdata_dir}"; then
    usermod -u $(stat -c "%u" "${appdata_dir}") www-data
    groupmod -g $(stat -c "%g" "${appdata_dir}") appgroup
else    ## not mounted; ensure appdata_dir exists:
    mkdir -p "${appdata_dir}"
    chown -c -R www-data:appgroup "${appdata_dir}"
    chmod -c -R g+rwX "${appdata_dir}"
fi

The above script worked well enough but there were few problems:

Occasionally application failed to start after changes in the container. This happened because of clash between external UID/GID and the same UID or GID allocated to another user in the container.

This approach needs extra capabilities ("CAP_SETGID","CAP_SETUID") as by default root is restricted in rkt containers.

As usual, superior approach is also simpler: standardise UID/GID and hard-code them in the container build script as follows:

## Existing user and group.
usermod  --uid 111 apt-cacher-ng
groupmod --gid 119 apt-cacher-ng
id apt-cacher-ng    # optional

## New user and group.
groupadd --gid 152 elasticsearch
adduser --system --uid 138 --gid 152 elasticsearch
id elasticsearch    # optional

Please consider supporting our work through Donations.

Tags: