Container generated files gets wrong uid & gid on host machine

[ARehmanMahi]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: 2f8f483e-e3ac-44f2-a1e6-8e6a31f5a6a2/20220618200955

Expected behavior

Container service generated files should have same uid on host

Actual behavior

Container service generated files have weird/wrong uid on host

Information

• Linux distro: Ubuntu
• Distro version: 22.04
• Docker Desktop Version: 4.9.1

Container generated files gets wrong uid & gid on host machine, even though container service in this case php-fpm has 1000 uid for user as defined in the docker file, details below.

I did a chown 1000:1000 on storage folder inside container, and after that I get the issue

docker-compose

version: '3.8'

services:
    php:
        build:
            context: .
            dockerfile: docker-files/php.dockerfile
            args:
                - user=jenkins
                - group=www-data
                - uid=1000
        container_name: php
        volumes:
            - .:/var/www/html/
        working_dir: /var/www/html/

    nginx:
        build:
            context: .
            dockerfile: docker-files/nginx.dockerfile
        container_name: nginx
        restart: always
        ports:
            - "80:80"
        volumes:
            - .:/var/www/html/
        working_dir: /var/www/html/
        extra_hosts:
            - "laravel-app.test:127.0.0.1"
        depends_on:
            - php

php.dockerfile

FROM php:8.1-fpm-alpine

ARG user
ARG group
ARG uid

RUN addgroup $user
RUN adduser -D -H -u $uid $user -G $user -s /bin/sh

RUN sed -i "s/user[ \t]*=[ \t]*www-data/user = $user/g" /usr/local/etc/php-fpm.d/www.conf
RUN sed -i "s/group[ \t]*=[ \t]*www-data/group = $group/g" /usr/local/etc/php-fpm.d/www.conf

[p1-0tr]

@ARehmanMahi - the weird uid/gids on the host are actually expected. We are running the file sharing daemon inside a user namespace with uid/gid remapping. This is done so that Docker Desktop can run as a regular user, and not restrict what's possible to do inside its containers (e.g. changing ownership of files). Your user's id and gid will be mapped to root inside the file sharing namespace, so you can chown files to root inside the container, which will mean they will be owned by your user on the host. It is also possible to reconfigure the subordinate id range (a range of uid/gid that your user is allowed to use), to map to meaningful ids on the host (<65k), by editing /etc/subuid and /etc/subgid, but I wouldn't advise doing that because you'd be effectively raising privileges of Docker Desktop.

[ARehmanMahi]

@p1-0tr Thanks for clearing that up for me, so root inside container is mapped to my host user. That is good so far as all root files are owned/accessible by host.

Can the container service (php-fpm) running inside container, be mapped to host user?
Like map www-data of php-fpm to host www-data? As those are the ones not accessible to host user.

You can close this issue. And if the above question is not relevant here, please point me to some direction.
Appreciate your time, Thanks again.

[p1-0tr]

@ARehmanMahi - currently there isn't a good way to do this, unfortunately. One way would be to do what I mentioned above, which would mean changing /etc/subuid and /etc/subgid to map to actual ranges on your host. Currently they probably have entries which look sth like this <your username>:100000:65536 (<user>:<begining of range>:<size>). Changing them to <your username>:1:65536, would result in uid/gid 1 in the container be mapped to uid/gid 1 (etc.) on the host. This is far from ideal because you effectively raise the privileges of your user. The best alternative would likely be to add a group with gid 100999 (sudo addgroup --gid 100999 <group name>) on your host, add your user to that group, and grant (in the container) group write access to files you want to modify. Would that work for you?

[ARehmanMahi]

I see, so mapping full range, doesn't sound so good as you already mentioned, But yes, your suggestion to add the 100999 into host is simpler I guess; that would work. I should read on security after I'm done with running my dev environment using docker :)

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked