Идеальная схема полномочий нескольких сайтов Apache/PHP

Ваш DNS плох: 208.111.94.17 17.94.111.208.in-addr.arpa указателя доменного имени ads.jeuxgratuits.net.

Таким образом, необходимо изменить DNS и ожидать распространения

4
задан 30 August 2014 в 10:57
5 ответов
chown -R :nobody root_of_all_sites
chmod g+rw -R root_of_all_sites

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

0
ответ дан 3 December 2019 в 04:16

Пользователи этих нескольких сайтов доверяют друг другу? Если так, для пользователей довольно легко иметь дело с этим самих. Весь пользователь должен должен быть сделать, делают соответствующий каталог world-accessible/writable с

chmod o+wx dir
chmod o+w dir/files_webserver_should_edit*

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

chmod g+s dir

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

chmod o+t dir
chmod g-w dir/files_not_to_be_altered*

Если у пользователя есть доступ для записи к каталогу, но не в файл в том каталоге, они могут удалить файл из каталога и создать новый, к которому у них ДЕЙСТВИТЕЛЬНО есть доступ для записи. Липкий бит (o+t) препятствует тому, чтобы пользователь удалил файл, которым они не владеют из каталога. С ними объединенными, Сценарий PHP может создать новые файлы и обновить и удалить файлы, которые они создают (так как они "никому" не будут принадлежать), но не может отредактировать "files_not_to_be_altered" и не может стереть их, так как они принадлежат "пользователю").

Это дает пользовательский элемент управления, по которому каталоги на самом деле перезаписываемы веб-сервером, и не требует корневого доступа, так как он не изменяет владение.

Если пользователи не будут доверять друг другу, то Вам будет нужно немного корневого вмешательства. Структуру каталогов каждого веб-сайта должны будут настроить однажды для преобразования ее владения:
Примечание: эти инструкции предполагают, что ничья группа - также никто, но некоторые системы используют nogroup

chown -R user:nobody /some/website
chmod -R g+rX,o-rwx /some/website

(капитал X добавляет x доступ к каталогам),

Это сделает дерево каталогов доступным для пользователя и никого и удалит всех доступ else. Пользователи могут продолжить двигаться оттуда самостоятельно, предоставив g+w доступ, где им нравится, однако они должны будут использовать u+s вместо g+s для обеспечения у них есть доступ к файлам, созданным веб-сервером. o+t будет работать, как предназначено.

Как в стороне, у Вас могут быть другие серверы с помощью nobody/nogroup... для уменьшения альтернативных методов нападения (использование в некотором другом сервисе, работающем как никто дающий взломщику способность записать в этих веб-сайтах), большинство систем имеет преданного пользователя/группу веб-сервера, которого только веб-сервер выполняет как.

0
ответ дан 3 December 2019 в 04:16

Необходимо рассмотреть расширенный ACLs. Поддерживаемый на FreeBSD и Linux, команда setfacl позволяет Вам определять больше чем 1 пользователя/группу, который имеет доступ к каждому файлу/каталогу. Вы не можете затем дать никому пользователя/группу, 'выполнить' разрешение / размещает/home/user. затем чтение и запись только на корне документа сайтов, где они требуют его.

В случае неудачи можно просто изменить группу корневого каталога каждых пользователей никому и использовать полномочия 710 на/home/username и затем показанный user:nobody и chmod 770 на корне документа.

Помните, что 'никто' пользователь потребует, 'выполнить' разрешение на каждом каталоге между / и корень документа (или просматривают определенное разрешение или 'другое' поле), и затем читало (и дополнительно пишет) на корне документа. Можно не разрешить всем другим пользователям читать или выполниться на пользовательском каталоге или корневом каталоге документа. Весьма распространено видеть / домой, где ни у кого кроме корня нет доступа для чтения, и все пользователи только имеют, выполняются. затем они могут добраться до/home/username, но они не могут получить список того, что другие пользователи существуют на сервере

1
ответ дан 3 December 2019 в 04:16

Вероятно, самый легкий способ сделать это должно использовать mpm-itk - он потребует, чтобы Вы переключили mpms, и действительно подвергается хиту производительности. Однако это позволит Вам настроить другого пользователя для Apache для использования на VirtualHost и не потребует никаких других изменений конфигурации. Я испытал его, и это довольно просто в использовании, и хит производительности не ужасен. YMMV, конечно...

0
ответ дан 3 December 2019 в 04:16

Для лучшей производительности необходимо выполнить Сценарии PHP как отдельный пользователь и показанный файлы так, чтобы у пользователя Apache только был доступ для чтения к ним.

Самый легкий должен использовать SuPHP: http://www.suphp.org/

Другая опция состоит в том, чтобы выполнить PHP в режиме CGI и удостовериться, что Apache настроен должностному лицу () каждый CGI под его собственным идентификатором пользователя. Инструкции здесь:

http://php.net/manual/en/security.cgi-bin.php

0
ответ дан 3 December 2019 в 04:16

Теги

Похожие вопросы