В настоящее время я настраиваю WordPress на сервере Ubuntu 12, все работает нормально, но возникает проблема, когда дело доходит до автоматического обновления и загрузки мультимедиа через WP, поскольку пользователь Apache «www-data» не имеет прав на запись в каталоги. "user1" имеет полное разрешение
Все мои каталоги имеют разрешения 0755 и файлы 644
мои каталоги настроены следующим образом:
/home/user1/public_html
Все файлы и каталоги WP находятся в "public_html"
Чтобы обойти автоматическое обновление и загрузку мультимедиа, я предоставил право собственности пользователю Apache на следующие каталоги
sudo chown www-data:www-data wp-content -R
sudo chown www-data:www-data wp-includes -R
sudo chown www-data:www-data wp-admin -R
Я хотел бы знать, насколько это безопасно, и если это не безопасно, что было бы лучшим решением?
Это позволит мне сохранить все файлы и каталоги, принадлежащие пользователю user1, и при этом wp сможет автоматически обновлять и загружать мультимедиа.
Я почти уверен, что уже отвечал на этот вопрос раньше, но я не могу найти вопрос, на который можно ссылаться.
Вы не должны спрашивать, безопасно ли использовать nnn. Безопасность никогда не бывает двоичной величиной, и вам почти всегда необходимо проводить более подробный анализ. Вопрос, который вы должны задать, - сделать nnn более или менее безопасным, чем альтернатива.
Да, изменение владельца файлов, чтобы Apache мог писать в них, увеличивает вероятность проблем, но это не единственный фактор.
Гораздо более серьезная проблема, если вы не измените владельца, захотите ли вы приложить усилия, чтобы веб-приложение обновлялось и исправлялось. Если у вас нет инструментов или возможности поддерживать его в актуальном состоянии и исправлять с использованием только интерфейса командной строки, то это потенциально гораздо более серьезная проблема безопасности, чем проблемы, которые могут возникнуть в результате более разрешительных разрешений файловой системы. .
У меня нет ссылки / справки, но я думаю, что где-то читал, что многие вещи скомпрометированы, потому что исправления для известных уязвимостей не применяются своевременно. OTOH, слабые права доступа к файловой системе обычно вступают в игру только в результате ошибки / проблемы в веб-приложении.
В идеале, если у вас есть требование к чрезвычайно сильной параноидальной безопасности, у вас должны быть чрезвычайно заблокированы разрешения и приложения, очень актуальные, но если бы мне пришлось выбрать одно, я бы обычно старался установить все исправления.
Вы, конечно, должны принять решение, исходя из потенциальных рисков и реалистичного понимания того, как вы будете обновлять и поддерживать систему.
На мой взгляд, можете ли вы считать это безопасным (небезопасным), во многом зависит от вашего варианта использования, ваших пользователей и вашей среды. Позвольте мне сказать это так: если вы планируете предоставлять веб-хостинг для платежеспособных клиентов и не находитесь в закрытой инфраструктуре или за невероятно сложной WAF или IPS, вы, вероятно, сочли бы это небезопасным. Здесь я имею в виду не только каталоги, доступные для записи, но и использование mod_php, что вы, кажется, делаете. Опять же, если вы просто настраиваете небольшой веб-хостинг для своих друзей и семьи, ожидаете около десяти посещений в неделю и у вас действительно нет времени, с вами, вероятно, все будет в порядке (однако я бы рекомендовал использовать некоторый доступный общий хостинг, в этом случае ).
Более безопасные альтернативы запускать выполнение PHP каждого пользователя под его собственными правами пользователя. Наиболее распространенные примеры:
В зависимости от ваших пользователей / среды / ... я бы рекомендовал карантин ваш ящик. В сценарии FastCGI вы должны использовать chroot и можете дополнительно укрепить вашу систему с помощью улучшений безопасности Linux (например, 1, 2, 3).
Но еще раз: вы действительно можете потратить на это много времени. Подумайте об использовании совместно используемой среды от хорошего хостера, который сделает это за вас, прежде чем выставлять небезопасный ящик на волю.
РЕДАКТИРОВАТЬ: удалено решение, которое все называют «плохим».
Оставив это на месте, которое все предпочли проигнорировать, потому что они не могли прочитать первые пять строк:
Вот альтернатива, с которой я сейчас экспериментирую:
$ chown someuser:other-users somefolder
$ chmod 770 somefolder
Это дает владельцу (someuser) и всем членам группы «other-users» (тому, кому «someuser» решает предоставить разрешения) разрешения на чтение / запись / выполнение. Сделайте chmod 660 для файлов.
Поскольку вы настраиваете работу под mod_php. Каждую минуту вы должны запускать пользователя cron.
Однако вы должны настроить работу под suphp для вашей проблемы.