Считается хорошей практикой на сайте ставить права доступа на папки с кодом только на чтение. А куда запись разрешена (cache, upload) вынести за пределы DocumentRoot или как-то иначе запретить там запуск скриптов через веб. Но если у вас есть система обновления, то очевидно нужны права на запись в папки со скриптами. Вот в WordPress, например, есть обновление ядра, плагинов и тем и это хорошо! Но страшно. Я меня тут происходит когнитивный диссонанс и расстройство. Как бы вы разрешили этот конфликт?
Никуда не выносил открытые каталоги, и не нужно это делать. К ним просто нужно убрать прямой доступ и всё. И, соответственно, правильно роутить запросы к статике которая там лежит на уровне приложения или на уровне перенаправлений по URL
Хорошо, но это не ответ на вопрос. Вынос папок не мешает обновляться. Помешать могут права: хочется их у www-data отнять, но тогда получается что через web-ный php нереально будет обновиться.
По хорошему пользователь должен иметь все необходимые права на директорию проекта. Зашита от записии выполнения чего-то вредоносного в каталог должна быть на уровне самого приложения я считаю. И всё же, как вариант, можно дергать команды на сброс прав до обновления и повторное закрытие от записи после самого обновления. Так насколько помню, тот же друпал когда инсталится сам выставляет права на свои каталоги.
ммм, нет. Нужны права доступа ОС, и тогда наверняка. А защита уровня приложения она сегодня есть, а завтра оказалось, что она уже год как не есть.
Делал так. Есть юзер SSH и есть юзер веб-сервера. Ну, в одной группе. Обновления от первого через wp-cli. Второму права на запись только на отдельные директории. В общем жизнеспособно, но немного гиморно. Так что если в этом WP нет каких-то критичных приватных данных ине очень критичен теоретический простой из-за взлома - не парится и давать права записи веб-серверу на обновление. Просто наладить частый бакап на другую машину, а если уж совсем параноя - отдельный cli по проверке целостности файлов по хешу, есть твсякие подобные решения.
Спасибо! Оба пользователя в одной группе это чтобы chmod g+w cache сделать? Это можно распостранить и не на cli. Чисто теоретически можно ведь на ту же площадку с другого домена/поддомена зайти под другой системной учеткой… И конечно забить на права всегда можно, это не фокус
Ну да, ну и вообще логическое объединение юзеров. Там еще формум, например, может жить... под 3-м юзером Да, так можно. Вообще админку направить на свой пул PHP со своим юзером. Но будет точка взлома