usermod for php containers
MaksimKiselev opened this issue · comments
How about add RUN usermod -u 1000 www-data for php containers? :)
Because now container set root permission for files which create.
AFAIR this setting strongly depends on your local development environment, i.e. host-OS and host-volumes.
What's your docker setup?
Currently I run this in the docker-entrypoint script:
# Set permissions based on ENV variable
if [ -x "usermod" ] ; then
usermod -u ${PHP_USER_ID} www-data
fi
Because now container set root permission for files which create.
@mkiselev I can not confirm that. Files created from PHP inside the container belong to www-data which has uid 33. So changing the uid to 1000 does not really help much: It just changes the static file uid from 33 to 1000.
Permission root is only set if you run CLI scripts which create a file e.g. with docker run .... But then changing the uid doesn't help either: New files will still be owned by root.
Maybe I misunderstood and you can give an example to clarify.
Example from container bash on OS X with docker-machine VM. My host user has id 501. composer files, src/ and vendor/ are host-volumes
phd root container 0128544c7c51 /app
$ ls -la
total 312
drwxr-xr-x 1 root root 4096 Apr 3 04:51 .
drwxr-xr-x 1 root root 4096 Apr 3 06:52 ..
-rw-r--r-- 1 root root 150 Jul 21 2016 .env
-rw-r--r-- 1 501 dialout 2466 Mar 28 09:06 composer.json
-rw-r--r-- 1 501 dialout 276781 Mar 28 09:06 composer.lock
drwxr-xr-x 2 root root 4096 Apr 3 04:51 data
drwxrwxr-x 2 1000 www-data 4096 Apr 3 04:51 runtime
drwxr-xr-x 19 501 dialout 646 Mar 28 08:39 src
drwxr-xr-x 62 501 dialout 2108 Apr 3 04:51 vendor
drwxr-xr-x 6 501 dialout 204 Mar 9 2016 web
-rwxr-xr-x 1 root root 896 Mar 9 2016 yii
I am using linux as host machine and in all my Dockerfiles:
[...]
# Add Group and User
RUN addgroup -S -g 1000 docker
RUN adduser -S -D -s /bin/bash -u 1000 -G docker docker
[...]
USER 1000
ENTRYPOINT ...
So my container runs as user and docker exec too,
@mkiselev Closing this for now as I don't see, how a usermod would help here (see my comment above). Permission setup depends a lot on your project's docker setup. So it's something a developer has to fix in the project's Dockerfile as shown by the examples of @schmunk42 and @Caravus.
@mikehaertl I think this should be a documentation issue then.
Well, we can add something. The problem is really only with files created during development in a directory mapped into the container. Migrations being the best example: They'll be owned by root on your host system if you create them inside a container. So you'd have to change ownership before you can modify them on your host.
There's usually no problem in production though. So I still think a little note about this is sufficient.
This issue also occurs when running i.e. yii commands which write to the local filesystem, usually as root. And if there are file-operations from fpm oder the web-server which run under a different user.
CC: @handcode
Docker version 17.03.1-ce, build c6d412e
docker-compose version 1.14.0, build c7bdf9e
image ubuntu 14.04
Step 6/7 : RUN addgroup -S -g 1000 docker
---> Running in f03213a81a82
Option s is ambiguous (shell, system)
Option g is ambiguous (gecos, gid, group)
adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
[--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID]
[--disabled-password] [--disabled-login] [--encrypt-home] USER
Add a normal user
adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
[--gecos GECOS] [--group | --ingroup GROUP | --gid ID] [--disabled-password]
[--disabled-login] USER
Add a system user
adduser --group [--gid ID] GROUP
addgroup [--gid ID] GROUP
Add a user group
addgroup --system [--gid ID] GROUP
Add a system group
adduser USER GROUP
Add an existing user to an existing group
general options:
--quiet | -q don't give process information to stdout
--force-badname allow usernames which do not match the
NAME_REGEX[_SYSTEM] configuration variable
--help | -h usage message
--version | -v version number and copyright
--conf | -c FILE use FILE as configuration file
ERROR: Service 'phpfpm' failed to build: The command '/bin/sh -c addgroup -S -g 1000 docker' returned a non-zero code: 1
Because switching the user on ie. Alpine was very difficult or it required dozens of MBs for additional tools, we ended up in doing:
if (getenv('PHP_USER_ID')) {
posix_setuid(getenv('PHP_USER_ID'));
}
In the yii CLI script.
Related: yiisoft/yii-base-web#1
taufik@lepie /tmp $ git clone https://github.com/yiisoft/yii2-docker.git
Cloning into 'yii2-docker'...
remote: Counting objects: 606, done.
remote: Total 606 (delta 5), reused 5 (delta 5), pack-reused 600
Receiving objects: 100% (606/606), 80.32 KiB | 0 bytes/s, done.
Resolving deltas: 100% (265/265), done.
Checking connectivity... done.
taufik@lepie /tmp $ cd yii2-docker/
taufik@lepie /tmp/yii2-docker $ cp .env-dist .env
taufik@lepie /tmp/yii2-docker $ xed ./php/Dockerfile-debian
I edited ENV PHP_USER_ID=33 \ to ENV PHP_USER_ID=1000 \
taufik@lepie /tmp/yii2-docker $ docker-compose build
WARNING: The GITHUB_API_TOKEN variable is not set. Defaulting to a blank string.
Building php
Step 1/13 : ARG PHP_BASE_IMAGE_VERSION
Step 2/13 : FROM php:${PHP_BASE_IMAGE_VERSION}
---> 732d9549c027
Step 3/13 : ENV DEBIAN_FRONTEND=noninteractive
---> Using cache
---> 7766162640db
Step 4/13 : RUN apt-get update && apt-get -y install gnupg2 && apt-key update && apt-get update && apt-get -y install g++ git curl imagemagick libfreetype6-dev libcurl3-dev libicu-dev libfreetype6-dev libjpeg-dev libjpeg62-turbo-dev libmagickwand-dev libpq-dev libpng-dev libxml2-dev zlib1g-dev mysql-client openssh-client nano unzip --no-install-recommends && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
---> Using cache
---> e54d53276c17
Step 5/13 : RUN docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-png-dir=/usr/include/ --with-jpeg-dir=/usr/include/ && docker-php-ext-configure bcmath && docker-php-ext-install soap zip curl bcmath exif gd iconv intl mbstring opcache pdo_mysql pdo_pgsql
---> Using cache
---> 61a124ff3b42
Step 6/13 : RUN printf "\n" | pecl install imagick && docker-php-ext-enable imagick
---> Using cache
---> 2885282800eb
Step 7/13 : ENV PHP_USER_ID=1000 PHP_ENABLE_XDEBUG=0 PATH=/app:/app/vendor/bin:/root/.composer/vendor/bin:$PATH TERM=linux VERSION_PRESTISSIMO_PLUGIN=^0.3.7 COMPOSER_ALLOW_SUPERUSER=1
---> Using cache
---> 4251375dc0f6
Step 8/13 : COPY image-files/ /
---> Using cache
---> 8060d13ab25b
Step 9/13 : RUN chmod 700 /usr/local/bin/docker-php-entrypoint /usr/local/bin/composer
---> Using cache
---> 620b00ef6b53
Step 10/13 : RUN curl -sS https://getcomposer.org/installer | php -- --filename=composer.phar --install-dir=/usr/local/bin && composer clear-cache
---> Running in b7ef2bec7b4e
curl: (6) Could not resolve host: getcomposer.org
/usr/local/bin/composer: line 10: composer.phar: command not found
ERROR: Service 'php' failed to build: The command '/bin/sh -c curl -sS https://getcomposer.org/installer | php -- --filename=composer.phar --install-dir=/usr/local/bin && composer clear-cache' returned a non-zero code: 127
how to fix this. because when I set to default PHP_USER_ID = 33 it run normally
That's strange, because your error says:
curl: (6) Could not resolve host: getcomposer.org
/usr/local/bin/composer: line 10: composer.phar: command not found
Actually you should not change that in the Dockerfile it's meant to be changed in docker-compose.yml
I modify Dockerfile-debian to ENV PHP_USER_ID=1000 because PHP_USER_ID=1000 at .ENV didnt work. www-data still 33
at end, I add
RUN usermod -u 1000 -s /bin/bash www-data && groupmod -g 1000 www-data
at the end of Dockerfile-debian, and it work now
(I add /bin/bash because I want run composer for my project inside docker)
But when you enter the container to run composer you are root and the above should have no effect - or are you another user?
I enter container with:
docker-compose exec php su www-data
and then, I run composer (as www-data 1000)
Why do you want to run composer as www-data and not as root?
usermod should be available on the Debian images.
Why do you want to run composer as www-data and not as root?
I totally agree on a standard (bare-metal, non-VM) system.
But what's an attack scenario in a container? Doesn't www-data need to have effectively the same permissions as root?
[addon] We also disable the warning btw https://github.com/yiisoft/yii2-docker/blob/master/php/Dockerfile-debian#L86