Я имел опыт программирования и был брошен управлять сервером Linux на работе из-за чрезвычайной ситуации с нашим администратором reg sys. Надежно или безопасно, чтобы наши файлы PHP принадлежали пользователю root, а Apache, очевидно, работал в Fedora 8 как apache?
Apache дает права на чтение и в незначительных случаях, таких как каталог загрузок, права записи с помощью chmod 777 для этой папки загрузок.
Мы запускаем mod_security, но задались вопросом, есть ли лучшая практика. Я один в этом вопросе следующие 2-3 недели, пока системный администратор восстанавливается.
Если вы используете PHP так, как он работает от имени пользователя Apache (например, «www-data» в системах debian, «никто» на общих хостах CentOS + cPanel, ...), то владелец файла на самом деле не Дело в том, что он вызывается через Apache - PHP, и поэтому скрипт всегда будет выполняться от имени пользователя Apache, а не от пользователя, владеющего файлом.
Если вы запускаете PHP как модуль, то это почти наверняка так.
Если у вас есть PHP, настроенный для запуска скриптов от имени конкретного пользователя (через suphp, suexec или аналогичный - вы можете делать это, если вы запускаете PHP через методы CGI или FastCGI), то наличие файлов скриптов, принадлежащих привилегированному пользователю, очень плохо идея.
Что касается разрешений «777», этого тоже следует избегать, особенно если вы не единственный пользователь на сервере. Вместо этого я бы удостоверился, что каталог принадлежит пользователю. Apache будет запускать PHP под именем «700» (или в группе, в которой этот пользователь также находится и использует 770). Для большей паранойи, если ваши скрипты всегда будут знать имя файла, которое им нужно, и им не нужно читать список каталогов, запретите также разрешение на выполнение в каталоге.
Также никогда не делайте скрипты доступными для записи во всем мире. Настройки suPHP по умолчанию на самом деле немного защищают вас от этого, отказываясь запускать скрипты с разрешениями, доступными для записи всем (или в каталогах, которые есть).
Как правило, я избегаю использования менее ограничительных разрешений при разработке, чем это было бы необходимо в живой, общедоступной среде. Это позволяет избежать случайного выхода перма излишне разрешающей при продвижении кода в живую и избежать появления ошибок, когда ваш код предполагает более разрешительный доступ, чем это разрешено в реальной среде.
Какая группа владеет файлами PHP? Ваше упоминание о 777 предполагает, что это «wheel» или «adm» или какая-то другая привилегированная группа, так что единственный способ, которым Apache может увидеть любой файл, - это когда этот файл доступен для чтения всем. Или с возможностью записи всем, в случае папки загрузок.
Это почти наверняка нехорошо, хотя серьезность будет зависеть от того, что все, что вы используете на сервере (как веб-интерфейс, так и другие), содержит ли какой-либо из скриптов PHP учетные данные в виде открытого текста и т. Д.
Если, с другой стороны, файлы принадлежат gid, под которым работает Apache, то вы в несколько лучшем состоянии. Теоретически вы могли бы сделать chmod -R o-rwx на DocumentRoot, чтобы удалить все «мировые» привилегии, и, скорее всего, все будет хорошо и безопасно, а ваши веб-страницы по-прежнему будут работать.
Но тогда возникает вопрос о битах setuid. Я не совсем уверен, можно ли на практике использовать PHP-скрипт, принадлежащий root, с включенным setuid, в злонамеренных целях, но я бы не хотел, чтобы он был на моем веб-сервере.
И даже если setuid не беспокоит, мне все равно не нравится root-владение.
Разрешения 777 обычно считаются плохой идеей для скриптов PHP. Если файлы принадлежат пользователю root, вы, вероятно, захотите, чтобы они, по крайней мере, принадлежали группе apache, чтобы они не были доступны для чтения всем, если это не то, что вы хотите. Таким образом вы можете сократить до 770 разрешений. (Кажется немного странным, что скрипты тоже принадлежат root.)
В будущем вам также может потребоваться установить бит закрепления в каталоге, чтобы новые файлы, добавленные в этот каталог, автоматически chgrp заносились в любую группу, владеющую каталогом, с помощью следующей команды:
chmod 2775 / путь / к / каталогу
Таким образом, вы можете (например) установить владельца группы каталогов, которые вы обслуживаете, для apache, и новый контент, который будет добавлен, автоматически будет в группе apache и, следовательно, доступен для чтения без необходимости предоставления разрешений для чтения всем (при условии, что соответствующий umask).