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


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

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

Доступ нужен только двум объектам.

  1. PHP / Perl / рубин / 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 резко меняется, поскольку одно из четырех вышеперечисленных объектов всегда добавляет (а иногда и удаляет) папки и подпапки на многие уровни в глубину. Они также создают и удаляют файлы, к которым другим 3 сущностям может понадобиться доступ для чтения / записи. Таким образом, разрешения должны сделать четыре вещи выше для файлов и каталогов. Поскольку ни одно из них не должно требовать разрешения на выполнение (см. Вопрос о ruby ​​/ php выше), я бы предположил, что rw-rw-r-- разрешение будет всем, что необходимо и полностью безопасно, поскольку эти четыре сущности управляются доверенный персонал (см. № 2), и все остальные пользователи в системе имеют доступ только для чтения.

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

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

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


60
2018-03-22 01:21


Источник




Ответы:


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


45
2018-03-25 21:27



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


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

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

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


8
2018-03-22 02:52



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


После проведения дополнительных исследований кажется, что git / svn ИНСТРУМЕНТЫ НЕ являются проблемой, поскольку они работают как любой пользователь, использующий их. (Тем не менее, демоны 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-data

Затем нам нужно добавить текущего пользователя (и любого другого) в группу 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 получить к ним доступ?


6
2018-03-24 03:15



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


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

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

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

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

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


5
2018-03-22 03:37



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


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

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

Вот руководство по использованию списков ACL. В зависимости от вашего дистрибутива ваше ядро ​​может уже включать поддержку ACL.

http://www.cs.unc.edu/cgi-bin/howto?howto=linux-posix-acls


2
2018-03-26 10:44



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


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

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 {} \;

1
2017-09-24 18:08





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


0
2017-12-09 05:38