Как настроить разрешения Linux для папки WWW?

Обновленное резюме

Каталог / var / www принадлежит, root:rootчто означает, что никто не может его использовать, и он совершенно бесполезен. Поскольку нам всем нужен веб-сервер, который действительно работает (и никто не должен входить в систему как «root»), мы должны это исправить.

Только два объекта нуждаются в доступе.

1. PHP / Perl / Ruby / Python все нуждаются в доступе к папкам и файлам, так как они создают многие из них (то есть /uploads/). Эти языки сценариев должны работать под nginx или apache (или даже чем-то вроде FastCGI для PHP).

2. Разработчики

Как они получают доступ? Я знаю, что кто-то где-то делал это раньше. Однако при наличии множества миллиардов веб-сайтов можно подумать, что по этой теме будет больше информации.

Я знаю, что 777 - полное разрешение на чтение / запись / выполнение для владельца / группы / другого. Так что, похоже, это не нужно корректно, поскольку дает случайным пользователям полные права.

Какие разрешения необходимо использовать, /var/wwwчтобы:

1. Контроль исходного кода, например, git или svn
2. Пользователи в группе, такие как «сайты» ( или даже добавленные в «www-данные» )
3. Сервера типа apache или lighthttpd
4. И PHP / Perl / Ruby

можно ли там читать, создавать и запускать файлы (и каталоги)?

Если я прав, сценарии Ruby и PHP не «выполняются» напрямую, а передаются интерпретатору. Таким образом, нет необходимости в разрешении на выполнение файлов в /var/www...? Таким образом, кажется , что правильное разрешение было бы chmod -R 1660что сделало бы

1. все файлы доступны для этих четырех объектов
2. все файлы не могут быть выполнены по ошибке
3. полностью заблокировать всех остальных из каталога
4. установить режим разрешений «липкий» для всех будущих файлов

Это верно?

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

Обновление 2: Структура папок /var/wwwкардинально меняется, так как одна из четырех сущностей выше всегда добавляет (и иногда удаляет) папки и подпапки на несколько уровней. Они также создают и удаляют файлы, которые могут понадобиться другим 3 объектам для чтения / записи. Следовательно, разрешения должны выполнять четыре действия, указанные выше, как для файлов, так и для каталогов. Поскольку ни одному из них не нужно разрешение на выполнение (см. Вопрос о ruby ​​/ php выше), я бы предположил, что rw-rw-r--разрешение - это все, что необходимо и полностью безопасно, поскольку эти четыре объекта управляются доверенным персоналом (см. # 2) и всеми другими пользователями на система имеет доступ только для чтения.

Обновление 3: это для персональных машин разработки и серверов частной компании. Нет случайных «веб-клиентов», как общий хост.

Обновление 4: эта статья от slicehost, кажется, лучше всего объясняет, что необходимо для настройки разрешений для вашей папки www. Тем не менее, я не уверен, какой пользователь или группа apache / nginx с PHP ИЛИ запускают svn / git и как их изменить.

Обновление 5: я (думаю) наконец нашел способ заставить все это работать (ответ ниже). Тем не менее, я не знаю, если это правильный и безопасный способ сделать это. Поэтому я начал щедрость. Человек, у которого есть лучший метод защиты и управления каталогом www, побеждает.

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

1. sudo usermod -a -G developer user1 (добавить каждого пользователя в группу разработчиков)
2. sudo chgrp -R developer /var/www/site.com/ чтобы разработчики могли там работать
3. sudo chmod -R 2774 /var/www/site.com/ так что только разработчики могут создавать / редактировать файлы (другой мир может читать)
4. sudo chgrp -R www-data /var/www/site.com/uploads так что www-data (apache / nginx) может создавать загрузки.

Поскольку он gitработает так, как его называет пользователь, тогда, пока пользователь находится в группе «разработчик», он должен иметь возможность создавать папки, редактировать файлы PHP и управлять репозиторием git.

Примечание. На шаге (3): «2» в 2774 означает «установить идентификатор группы» для каталога. Это приводит к тому, что новые файлы и подкаталоги, созданные в нем, наследуют идентификатор группы родительского каталога (вместо основной группы пользователя). Ссылка: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

Я не уверен, правильно ли это, но вот что я делаю на своем сервере:

• / var / www содержит папку для каждого веб-сайта.
• У каждого веб-сайта есть назначенный владелец, который устанавливается как владелец всех файлов и папок в каталоге веб-сайта.
• Все пользователи, которые поддерживают веб-сайт, помещаются в группу для веб-сайта.
• Эта группа устанавливается как владелец группы всех файлов и папок в каталоге.
• Любые файлы или папки, которые должны быть записаны веб-сервером (например, PHP), имеют своего владельца, измененного на www-data, под которым работает пользователь apache.

Имейте в виду, что у вас должен быть включен бит выполнения для каталогов, чтобы вы могли перечислить содержимое.

После дальнейших исследований кажется, что git / svn TOOLS НЕ являются проблемой, поскольку они работают так, как их использует пользователь. (Тем не менее, демоны git / svn - это другое дело!) Все, что я создал / клонировал с помощью git, имело мои разрешения, и был указан инструмент git, /usr/binкоторый подходит для этого тезиса.

Разрешения Git решены.

Разрешения пользователей, по-видимому, можно решить, добавив всех пользователей, которым необходим доступ к каталогу www, в www-dataгруппу, под которой работает apache (и nginx).

Таким образом, кажется, что один ответ на этот вопрос выглядит так:

По умолчанию /var/wwwпринадлежит root:rootи никто не может добавлять или изменять файлы там.

1) Изменить владельца группы

Сначала нам нужно изменить группу каталогов www, которая будет принадлежать "www-data" вместо "root" group

sudo chgrp -R www-data /var/www

2) Добавить пользователей в www-данные

Затем нам нужно добавить текущего пользователя (и любого другого) в группу www-data

sudo usermod -a -G www-data demousername

3) CHMOD www каталог

Измените права доступа, чтобы ТОЛЬКО владелец (root) и все пользователи в группе «www-data» могли rwx (чтение / запись / выполнение) файлы и каталоги ( никто другой даже не мог иметь к ним доступ ).

sudo chmod -R 2770 /var/www

Теперь все файлы и каталоги, созданные любым пользователем, который имеет доступ (т. Е. В группе "www-data"), будут доступны для чтения / записи apache и, следовательно, php.

Это верно? А как насчет файлов, которые создают PHP / Ruby - могут ли пользователи www-data получить к ним доступ?

Липкость не наследование разрешений. Прилипание к каталогу означает, что только владелец файла или владелец каталога может переименовать или удалить этот файл в каталоге, несмотря на то, что в разрешениях указано иное. Таким образом 1777 по / тмп /.

В классическом Unix отсутствует наследование разрешений на основе файловой системы, только на основе текущего процесса umask. В * BSD или Linux с setgid в каталоге поле группы вновь создаваемых файлов будет установлено так же, как поле родительского каталога. Для чего-то большего вам нужно взглянуть на ACL с ACL по умолчанию для каталогов, которые позволяют вам наследовать разрешения.

Вы должны начать с определения: * какие пользователи имеют доступ к системе * какова ваша модель угроз

Например, если вы делаете веб-хостинг с несколькими клиентами и не хотите, чтобы они видели файлы друг друга, тогда вы можете использовать общую группу «webcusts» для всех этих пользователей и режим каталога 0705. Затем файлы обслуживаются процесс веб-сервера ( не в "webcusts") увидит другие разрешения и будет разрешен; клиенты не могут видеть файлы друг друга, а пользователи могут связываться со своими файлами. Тем не менее, это означает, что в момент, когда вы разрешаете CGI или PHP, вы должны убедиться, что процессы запускаются от имени конкретного пользователя (в любом случае, это полезно для нескольких пользователей на одном хосте для обеспечения подотчетности). В противном случае клиенты могут связываться с файлами друг друга, заставляя CGI делать это.

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

Я считаю, что лучший способ сделать это - использовать Posix ACL. С ними удобно работать и они предлагают всю необходимую вам функциональность.

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs

Владельцем файла должен быть человек, который его создает, а в группе должны быть www-данные. Режим для каталогов / файлов тогда в целом 755/644. В то время как для каталогов и файлов группе необходим доступ для записи, мод - 775/664. Предположим, Пэдди является разработчиком. В целом это делает:

chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;  
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;

В дополнение к ответу @ Xeoncross, я думаю, было бы хорошо настроить разрешения для файлов и каталогов отдельно.

sudo find /var/www -type d -exec chmod 775 {} \;  # Change permissions of directories to rwxrwxr-x
sudo find /var/www -type f -exec chmod 664 {} \;  # Change file permissions to rw-rw-r--

Это позволит разработчикам создавать и изменять каталоги в / var / www. Что кажется важным, поскольку разработчикам может потребоваться создать дополнительные каталоги или удалить каталог, который больше не нужен.

Это также позволит разработчикам создавать и изменять файлы кода (читать HTML, файлы PHP и тому подобное). Но все равно разрешит доступ только для чтения всем остальным.