на centos 7 я создал сайт wordpress с корневым каталогом владельцаимя_сайта:группа_сайтови разрешения каталога755, права доступа к файлам644установлено по умолчанию
когда разработчик вошел в панель управления WordPress и попытался загрузить что-то на медиа или установить плагины, WP сказал, что нет разрешения на запись,
затем мне пришлось дать разрешения g+w для корневого каталога wp, после чего он смог установить плагин или загрузить медиафайлы.
после загрузки медиафайлов разрешение загруженного плагина/медиафайла меняется наапач:апачотимя_сайта:группа_сайтов
как избежать?
- Я даю разрешения g+x для корневого каталога wp, чтобы позволить разработчику устанавливать плагины/загружать медиа
- и право собственности на любую загрузку из wp dashboar не должно меняться на apache:apache
что я пробовал
В настоящее время я не нашел альтернативы, чтобы остановить это, каждый раз мне приходилось давать разрешения g+w и отменять их после работы разработчика.
решение1
Веб-серверу (или процессу PHP, в зависимости от настроек) требуется доступ на запись в каталог. Единственный возможный способ — запустить этот процесс как пользователь websitename.
Принципиально другим вариантом было бы предоставить пользователю apacheправа на запись через ACL или путем добавления его в websitegroupгруппу, но это также приведет к тому, что загружаемые файлы будут принадлежать apache. Если вы хотите, чтобы все файлы и папки принадлежали , websitenameвам нужно запустить веб-сервер от имени этого пользователя.
решение2
Ваше описание того, как это реализовано, бесполезно. Давайте начнем с нуля.
Пользователи:
- apache - uid, который выполняет ваша среда выполнения PHP
- dev1, dev2, dev2 - разработчики
- резервное копирование - для создания резервных копий сайта
- поддержка[n] - для расследования проблем
Из-за особенностей архитектуры Wordpress с ним очень сложно работать, если у «apache» нет полного доступа на чтение и запись к сайту.
Если все управление осуществляется через веб-интерфейс, разработчикам не нужнолюбойдоступ к файлам в корне документа. Однако я видел сайты, где разработчики регулярно используют CLI-доступ к обновленным файлам. Так что предположим, что им нужен доступ на чтение/запись.
Резервным копиям UID необходим доступ только для чтения к файлам.
Поддержке необходим доступ только для чтения к файлам.
Остается только пользователь сайта. Это ваша конструкция. При отсутствии дополнительной информации о том, как вы это используете, это кажется совершенно излишним.
Итак, единственные классы доступа — чтение+запись и только чтение. Но просто ради забавы мы скажем, что есть дополнительный класс без доступа — и назовем этого пользователя «чужим».
Право собственности пользователя всегда определяется uid, создающим файл, и является единственным значением для пользователя. Поэтому мы не можем использовать это как механизм для разрешения доступа.
Однако пользователи могут принадлежать к нескольким группам, и в каждой группе может быть несколько пользователей. Поэтому мы можем связать привилегию чтения-записи с определенной группой. Назовем ее webupdate.
Это оставляет доступ только для чтения (резервное копирование и поддержка), который может быть предоставлен через «другие» биты разрешений.
Но как тогда исключить "чужого"? Помещая сайт в каталог, к которому у чужого нет доступа - это значит, что нам нужна еще одна группа, которая идентифицирует людей, которые имеютнекоторыйдоступ. Назовем это веб-доступом.
Итак, состав группы:
- веб-обновление: apache, dev1, dev2...devn
- веб-доступ: apache, dev1, dev2...devn, резервное копирование, поддержка[n]
затем у нас есть каталоги, разрешения и права собственности:
drwxr-x--- root:webaccess /var/www/SITENAME
drwxrwxr-x ????:webupdate /var/www/SITENAME/html (document root)
Все хорошо, но когда кто-то в "webupdate" создает новый файл или каталог в корне документа, владельцем группы будет его группа DEFAULT, а не webupdate. Вы можете изменить это поведение с помощью бита setgid для каталогов:
drwxrwSr-x ????:webupdate /var/www/SITENAME/html
Последняя часть головоломки — убедиться, что umask установлен на 00x для членов webupdate, чтобы новые файлы и каталоги получали правильные разрешения. Не забудьте установить это в вашем sshd_config для сервера sftp, а также для интерактивных оболочек.
Поэтому, как только группы будут созданы, вы можете запустить:
chown -R apache:webupdate /var/www/SITENAME/html
chmod -r g+s /var/www/SITENAME/html
И все — вам больше никогда не придется исправлять разрешения.