Что такое идеальные полномочия Unix для обычных каталогов веб-проекта?

Предполагая, что «веб-приложение» запускается на сервере (например, apache, nginx и т. д.) и написан на каком-то динамическом языке сценариев (например, PHP, Ruby и т. д.), вы не понимаете, кто такой «пользователь».

Пользователь не является человеком кто вошел в ваше приложение - это и их роль в приложении (администратор и т. д.) совершенно не имеет отношения к сценарию. Пользователь - это пользователь системы Linux, в которой выполняется процесс. Код вашего веб-сайта запускается только одним пользователем - это может быть пользователь вашего веб-сервера (что на самом деле не очень хорошо), или это может быть пользователь, специфичный для вашего сайта (что намного лучше).

В Linux, пользователи принадлежат к группам - мы можем добавить пользователя в другую группу и назначить привилегии этой группе.

При хорошей настройке ваш сервер будет работать как один пользователь (назовем этого пользователя «веб-сервер»), а ваш динамический язык сценариев будет работать ( например, через FastCGI) в качестве собственного пользователя (один пользователь на сайт - назовем нашего первого пользователя site1).

Для обслуживания ваших файлов веб-серверу необходим доступ к ним, а языку сценариев необходим доступ к ним. Это означает: «site1» и «веб-сервер» должны иметь возможность читать ваши файлы. Однако только один из них может «владеть» файлами. Владелец - «пользователь» (пользователь, группа, другие). Нам также нужен наш язык сценариев, чтобы иметь возможность записывать в каталог (и читать файлы, которые он написал). Следовательно, пользователю site1 требуются разрешения на чтение и запись. а скорее считываются в интерпретаторе - для запуска типичного сценария (который ничего не записывает) необходимы только разрешения на чтение.

Разрешение на выполнение для каталогов имеет другое значение - оно разрешает обход без возможности прочтите содержание. Чтобы иметь возможность читать файл в каталоге, пользователь должен иметь права на выполнение для КАЖДОГО каталога над ним.

Для веб-приложения каждый файл должен иметь разрешения на чтение от своего владельца - в противном случае это довольно бессмысленный файл. Независимо от того, загружает ли файлы (через ваше веб-приложение) пользователь или администратор, «владельцу» (т.е. динамическому языку) требуются права на запись. Эффективная установка будет пытаться обслуживать статические файлы напрямую через веб-сервер, поскольку динамические языки, как правило, медленны при чтении больших файлов и отображении содержимого. Поэтому веб-серверу требуется доступ для чтения к вашим статическим файлам.

Следовательно, минимальные права доступа к файлам могут быть такими:

• Файл в каталоге, в котором будут размещаться загруженные пользователем статические файлы (файлы images / swf / js): 640
• Файл в каталоге, в котором будут находиться статические файлы, загруженные администратором (изображения / swf / js-файлы): 640
• Файл в каталоге, в котором находятся библиотеки, используемые в приложении: 400 (или 440)
• Файл в каталоге, где будут находиться исполняемые / просматриваемые сценарии на стороне сервера: 400 (или 440)
• Файл в каталоге, в котором уже существующие файлы (txt или xml) будут редактироваться кодом на стороне сервера: 640 или 600
  • (зависит от того, будет ли их отображать веб-сервер, иногда без изменений)

Хотя минимальные права доступа к каталогу могут быть:

• Каталог, в котором будут находиться загруженные пользователем статические файлы (файлы изображений / swf / js) : 750
• Каталог, в котором будут находиться статические файлы, загруженные администратором (изображения / swf / js-файлы): 750
• Каталог, в котором находятся библиотеки, используемые в приложении: 500 (или 550) [должно быть не менее 510]
• Каталог, в котором будут находиться исполняемые / просматриваемые сценарии на стороне сервера: 500 (или 550) [должно быть не менее 510]
• Каталог, в котором уже существующие файлы (txt или xml) будут редактироваться кодом на стороне сервера: 750 или 700
  • (зависит от того, будет ли веб-сервер обслуживать файлы отсюда, временами без изменений)

Еще раз - ваш веб-сервер должен иметь разрешения на выполнение для каждого каталога выше того, к которому ему нужен доступ - поэтому даже если веб-сервер не будет обслуживать файлы из данного каталога, мы должны предоставить ему разрешения на выполнение.

Довольно часто веб-сервер предоставляет доступ для чтения к большинству файлов (поэтому измените эти 500 на 550). По умолчанию «несколько безопасные» разрешения обычно составляют 755 для каталогов и 644 для файлов - нет разрешений на выполнение, каждый может читать и только пользователь может писать - вы заметите, что подавляющее большинство файлов в системе Linux имеют эти разрешения.

Имейте в виду, что «прочие» разрешения относятся к любому пользователю системы, который не является владельцем или членом группы (то есть всем остальным пользователям системы). Сохранять ограничения для ваших «других» разрешений - это хорошо, потому что эти пользователи неизвестны - вы явно не дали им разрешение. Другие разрешения часто проще всего использовать в скомпрометированной системе (например, одна из причин, почему / tmp является общей целью).

В контексте вышеизложенного я не думаю, что ваши последние два вопроса являются что актуально. Установите права доступа к каталогу на 550 (и права доступа к файлам на 440), а затем предоставьте пользователю права на запись для любых каталогов, в которые ваше приложение будет писать (например, каталог: 750; файл: 640).

(Вам, очевидно, понадобится запись разрешения на загрузку файлов - но, если хотите, вы можете удалить их позже - возможно, хотя,