Назад | Перейти на главную страницу

Как настроить разрешения 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-data")
  3. Серверы вроде apache или lighthttpd
  4. И PHP / Perl / Ruby

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

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

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

Это верно?

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

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

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

Обновление 4: Эта статья by 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 ИНСТРУМЕНТЫ НЕ являются проблемой, поскольку они запускаются от имени любого пользователя, который их использует. (Однако демоны git / svn - другое дело!) Все, что я создал / клонировал с помощью git, имело мои разрешения, а инструмент git был указан в /usr/bin что соответствует этому тезису.

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

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

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

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

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

Сначала нам нужно изменить группу каталогов www, чтобы она принадлежала «www-data» вместо «root» группы.

sudo chgrp -R www-data /var/www

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

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

sudo usermod -a -G www-data demousername

3) www-каталог CHMOD

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

sudo chmod -R 2770 /var/www

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

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

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

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

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

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

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

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

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

Владельцем файла должен быть человек, который его создает, а группа должна быть www-data. Тогда режим для каталогов / файлов обычно 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 и т.п.). Но по-прежнему будет разрешен доступ только для чтения для всех остальных.