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

Каковы идеальные минимальные разрешения в восьмеричном формате для следующего написанного в веб-приложении?

1. Каталог, в котором будут находиться загруженные пользователем статические файлы (файлы images / swf / js)
2. Каталог, в котором будут находиться загруженные администратором статические файлы (файлы images / swf / js)
3. Каталог, в котором находятся библиотеки, используемые в приложении
4. Каталог, в котором будут находиться исполняемые / доступные для просмотра серверные сценарии
5. Каталог, в котором уже существующие файлы (txt или xml) будут редактироваться кодом на стороне сервера.

Вот мои предложения и обоснования

1. 555, каждый может читать и писать, никто не может выполнить
2. 544, только владелец может писать, все остальные могут только читать, никто не может выполнить
3. 000, никому не нужно читать, писать и выполнять, будет использоваться только веб-сервером?
4. 661, владелец может читать, писать, все остальные могут только выполнять
5. 600, владелец может читать, писать (может и не понадобиться), никто другой не может ничего сделать

Теперь меня интересуют две вещи:

1. Есть ли что-то, что обычно используется в веб-приложениях, которые я пропустил в первом списке?
2. Есть ли что-то, с чем вы не согласны во втором списке, какая у вас альтернатива и почему она лучше?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это нормально иметь минимальный набор разрешений для выполнения работы. Если у вас есть веб-сервер, и пользователи имеют общую группу, вы можете отменить необходимость предоставления доступа o. Разрешения также связаны с пользователями. Похоже, вы неправильно поняли восьмеричные разрешения.

1. 555 r-xr-xr-xнет rw-rw-rw. Так как это каталог, то для создания / удаления файлов вам нужно xустановить так, чтобы 750 rwxr-x---был хорошим местом для начала. Это позволяет пользователю, владеющему каталогом, добавлять / удалять файлы, а все участники общей группы имеют к ним доступ.
2. Так же, как 1. выше.
3. Если бы они были действительно статическими файлами, то 050 предоставил бы доступ к веб-серверу, однако создание файлов в первую очередь было бы минимумом 750.
4. Так же, как 3 выше.
5. 070 - это минимум, позволяющий веб-серверу читать и изменять файлы, но файлы должны быть созданы, поэтому 770, вероятно, более реалистичен.

В общем случае можно использовать режим 0755, 0775 или 2775 для каталогов (бит SGID в каталогах, для BSD и для Linux, если файловая система смонтирована с семантикой BSD, чтобы сопоставление групп новых файлов соответствовало настройкам родительского каталога, а не GID по умолчанию создателя файла). Это позволяет всем пользователям проходить (chdir в и через) и читать (запускать команду ls или выполнять системные вызовы readdir / read) соответствующих каталогов. Альтернативы добавляют параметры группы / записи и, как отмечалось, бит SGID в каталогах, могут помочь сохранить все файлы и подкаталоги, связанные с подходящей группой.

Для файлов обычно используется 0644 или, возможно, 0664 (доступный для чтения и доступный для записи в группе или нет). Очевидно, что для CGI-скриптов и двоичных файлов нужно добавить x-бит; а для некоторых особых ситуаций с чрезвычайно хорошо протестированными двоичными файлами можно добавить биты SUID или SGID. Обычно UNIX и Linux игнорируют бит SUID / SGID в сценариях и учитывают его семантику только для встроенных скомпилированных исполняемых двоичных файлов. Однако ваш сайт может работать под чем-то вроде Apache с каким-то модулем, например, setuidhack, который может быть использован для того, чтобы веб-сервер учитывал биты SUID / SGID даже в интерпретируемых сценариях. (Это делается с помощью HTTP-демона stat () каждого файла и с использованием собственного пользовательского кода fork () / execve (), интерполирующего правильную строку интерпретатора в вектор execve () вместо простой передачи исполняемого файла '

Это только самые общие рекомендации. Они не «идеальны» для всех ситуаций, и вам обязательно нужно обратиться к документации по вашему веб-серверу и любым веб-приложениям или фреймворкам, которые вы устанавливаете и настраиваете ... и вы, возможно, захотите проконсультироваться с экспертом по безопасности UNIX перед тем, как выставить любые ваши файлы, код или серверы в общедоступный Интернет.