Как вы настраиваете права(владельца) на woprdress файлы, установленном через докер?

Question

[Islam Ibakaev]

В последнеее время для локальной разработки подтягиваю wordpress через докер. Подняв контейнер, можно увидеть, что все файлы принадлежат www-data:www-data
Для локальной работы такое не подходит, нужно поколдовать с разрешением на файлы. Тут два варианта, которые описаны здесь:
1) добавляем текущего пользователя(myusername) в группу www-data и меняем права на 775 и 664, соответственно
2) меняем владельца на текущего пользователя(myusername:www-data)

Какой по вашему способ предпочтительнее и почему? Какой вы используете?

UPDATED
Набрёл на пост, в котором автор предлагает выполнить bash скрипт

# try getting uid from docker, if it fails, try 33 (should work)
WWW_DATA_UID=33 # plug in your number from previous step
RESULT=$(docker-compose exec -u www-data wordpress id -u)
COMMAND_SUCCESS=$?
if [ $COMMAND_SUCCESS -eq 0 ]; then
  WWW_DATA_UID=$(echo $RESULT | tr -d '\r')
fi
sudo chown -R $WWW_DATA_UID:$USER ./wp-content
sudo find ./wp-content -type d -exec chmod 775 {} \;
sudo find ./wp-content -type f -exec chmod 664 {} \;

Я подумал его немного изменить: указать владельцем юзера, чтобы не менять права на файлы и папки.

# try getting uid from docker, if it fails, try 33 (should work)
WWW_DATA_UID=33 # plug in your number from previous step
RESULT=$(docker-compose exec -u www-data wordpress id -u)
COMMAND_SUCCESS=$?
if [ $COMMAND_SUCCESS -eq 0 ]; then
  WWW_DATA_UID=$(echo $RESULT | tr -d '\r')
fi
sudo chown -R $USER:$WWW_DATA_UID./wp-content

Что думаете насчёт моего варианта? Можно ли использовать или лучше юзать вариант автора поста и почему(если лучше)?

Comments

[mureevms]

Я бы посмотрел какой UID и GID пользователя www-data в контейнере и просто делал бы chown UID:GID /path/to/project -R

[Islam Ibakaev]

mureevms, а в чём смысл? файлы и папки итак принадлежат пользователю www-data

[Islam Ibakaev]

mureevms, дополнил вопрос, посмотрите, пожалуйста

[mureevms]

Islam Ibakaev,
sudo chown -R $WWW_DATA_UID:$USER ./wp-content
Это именно то, что я и предлагал

[Islam Ibakaev]

mureevms, возможно глупый вопрос, но всё же интересно в чём преимущества этого вариант перед

sudo chown -R $USER:$WWW_DATA_UID ./wp-content

[mureevms]

Islam Ibakaev, Все зависит, что скрывается за переменными. В данном случае это:
$WWW_DATA_UID - UID пользователя www-data внутри контейнера.
$USER - имя текущего пользователя в хост системе.
Таким образом, если вы делаете
chown $WWW_DATA_UID:$USER, владельцем становится пользователь www-data из контейнера и хостовая группа $USER, которая одноименна с хостовым пользователем $USER. Обычным пользователям UID и GID назначаются, начиная с 1000, пользователей и групп с такими ID нет в контейнере.
если chown $USER:$WWW_DATA_UID, то становится наоборот.

Было бы хорошо, если бы не было бессмыслено. Давайте посмотрим на дефолтные права файлов в контейнере (в выводе оставил один файл и один каталог, чтобы не было большой портянки, права на остальные одинаковы):

docker exec -it wordpress bash
root@e2c8d218cc9e:/var/www/html# ls -l
-rw-r--r--  1 www-data www-data   405 Feb  6  2020 index.php
drwxr-xr-x  9 www-data www-data  4096 Jan  6 19:13 wp-admin

Если сделать chown $WWW_DATA_UID:$USER, будет

-rw-r--r--  1 www-data 1000   405 Feb  6  2020 index.php

Если сделать chown $USER:$WWW_DATA_UID, будет

-rw-r--r--  1 1000 www-data   405 Feb  6  2020 index.php

Т.е. ни один способ не позволит либо менять файлы $USER, либо иметь доступ www-data юзеру. Именно поэтому и предлагается рекурсивно сделать chmod 775 для каталогов и chmod 664 для файлов, чтобы права появились.

PS: Мое первое предложение не состоятельно, поскольку подразумевал, что происходит на сервере из-под рута. Если это не привелегированный пользователь, то менять файлы так не получится.