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

69

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

Каталог / 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, побеждает.

Xeoncross
источник

Ответы:

47

После дополнительных исследований кажется, что другой (возможно, лучший способ) ответить на этот вопрос - настроить папку 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

Xeoncross
источник
Выглядит разумно для меня.
wazoox
Хороший. Возможно, если я смогу подтвердить это еще парой людей, я буду использовать этот подход. Кажется, это лучший ответ, который мне удалось выжать из людей.
Xeoncross
Вы не указываете, кто будет владельцем файлов. Вы бы оставили это как root? Тогда только пользователи sudoers могут редактировать вашу папку загрузок (вероятно, не то, что вы хотели).
Nic
Да, root останется владельцем. Однако, поскольку владелец группы теперь «разработчик» (и имеет разрешение wrx), тогда все разработчики (и apache / nginx) также могут читать. Нет необходимости в судо.
Xeoncross
7
Еще одна вещь, за которой нужно следить - это Umask. Многие системы имеют значение по умолчанию 022, которое удаляет права на запись как для группы, так и для публики в новых файлах. Я подозреваю, что вы хотите 002 (нет записи для общественности) или 007 (нет доступа для общественности). Вы можете установить umask в конфигурации Apache и / или в скриптах запуска для любого процесса, которому требуется доступ к каталогу. Не забудьте добавить это в / etc / profile или / etc / bashrc, чтобы оно также было установлено по умолчанию для ваших разработчиков
Марк Портер,
8

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

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

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

Nic
источник
Как тогда git / svn или PHP создают новые папки?
Xeoncross
2
PHP работает в том же пользовательском контексте, что и веб-сервер, поэтому он может создавать файлы и папки в любом каталоге, принадлежащем веб-серверу. Обычно таких папок немного (например, / uploads /). Я не уверен насчет git / svn - не могли бы вы добавить их в учетную запись группы, которая контролирует сайт?
Nic
по-видимому, git запускается от имени пользователя, как и любой другой инструмент.
Xeoncross
Затем добавьте пользователя git в группу apache и дайте разрешения на запись для группы папок.
Дэвид Рикман
Я только что сказал, у git нет пользователя - он работает как текущий пользователь, использующий его.
Xeoncross
7

После дальнейших исследований кажется, что 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 получить к ним доступ?

Xeoncross
источник
6
Мне не нравится идея сделать все веб-файлы доступными для записи с помощью PHP, это увеличивает вашу возможную уязвимость в случае уязвимости скрипта.
Nic
Хорошо, я знаю, что использую PHP для создания большого количества текстовых файлов, файлов tar, log и изображений (плюс папки), поэтому я просто предполагал, что все должно быть доступно для записи. Однако, возможно, ваше право, и PHP должен иметь возможность только ИЗМЕНИТЬ ФАЙЛЫ, КОТОРЫЕ ОНА СОЗДАЕТ, что было бы безопасно, поскольку 99% всех приложений PHP никогда не создают файлы сценариев. Другой выбор, по-видимому, заключается в том, чтобы разрешить доступ к записи PHP только определенным каталогам (/ uploads /), который с тех пор не создается, потому что тогда PHP все еще можно использовать для создания чего-то плохого. Есть идеи?
Xeoncross
2
Постарайтесь сохранить сценарий и данные отдельно. Даже если злоумышленнику удастся что-то добавить в / uploads /, он не должен быть исполняемым. Безопасность в слоях является ключевым.
Nic
6

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

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

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

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

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

Фил П
источник
Хороший ответ. В MacOS X система ведет себя так, как будто бит SGID автоматически попадает в каталоги. Заклепка обычно означает, что вы можете удалить файл, только если можете его записать. То есть любой может удалить общедоступный файл в / tmp. В MacOS X / tmp является символической ссылкой на личный каталог для пользователя - поэтому в конце концов нет общего доступа.
Джонатан Леффлер
Спасибо за ответ, я обновил вопрос с дополнительной информацией.
Xeoncross
Джонатан: залипающий бит означает, что только владелец каталога или владелец файла может переименовать или удалить его (т. Е. Действовать после его записи в каталоге «файл»). Разрешения для отдельного файла не вступают в действие для этих операций каталога ( rename(), unlink()), только для действий над самим файлом ( open()). Это «обычное» поведение.
Фил П
2

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

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

Tie-истребитель
источник
+1 за полезную информацию о ACL. Тем не менее, я не хочу лишнего мусора, который может заморозить систему, просто чтобы управлять простым сервером с парой разработчиков. Мне также неудобно перекомпилировать ядро ​​для использования ACL.
Xeoncross
@Xeoncross: списки ACL ничего не мешают. Они просто метаинформация как обычные права доступа к файлу. Это не все «лишнее» и сложное, я считаю, что это самый простой и лучший способ управления разрешениями, а не какое-то сбивающее с толку липкое / групповое / какое-либо решение. Не пугайтесь, просто переустановите с помощью acl и попробуйте!
Tie-fighter
1

Владельцем файла должен быть человек, который его создает, а в группе должны быть 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 {} \;
Jonny
источник
0

В дополнение к ответу @ 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 и тому подобное). Но все равно разрешит доступ только для чтения всем остальным.

MikeyE
источник