Apache, suexec, PHP, suPHP

13

В то время как я, как пользователь Linux , чувствую себя комфортно , мой Linux Admin-fu немного слабоват. Таким образом, я здесь ищу руководство по серверу CentOS, который собираюсь построить.

Мне нужно настроить веб-сервер Apache2 для нескольких наших клиентов. Я хочу, чтобы веб-контент каждого клиента находился в их домашнем каталоге ( USERDIRв apache.conf, верно?) Для статических сайтов HTML. Я хочу, чтобы Apache работал как клиент ( suexec?). Некоторые из них будут приложениями PHP, и у меня сложилось впечатление, что я тоже хочу посмотреть suphp.

В общем, я хочу выглядеть как маленькая версия хостинговой компании. Учитывая, насколько часто они бывают, я подумал, что легко найду хорошее руководство по настройке всего этого, но пока мне очень не повезло. Я подозреваю, что мои поисковые слова выключены.

Итак, вопросы (не стесняйтесь отвечать на любой или все):

  1. У кого-нибудь есть надежные ссылки на современные / современные руководства, которые помогут мне все это настроить? Нет, сайт документации apache не является руководством ;-)
  2. Так как у меня есть набор статических сайтов и приложений PHP, я хочу / нужно установить suexec и suphp? Если так, то это создает какие-то проблемы, о которых я должен знать?
  3. Стоит ли искать другие варианты вместо suexec и suphp?

Я планирую предоставить конечным пользователям SSH, SFTP или SCP доступ к своим материалам (если это повлияет на что-либо).

Заранее спасибо за помощь.

[Править] Я должен был упомянуть об этом раньше: одна из ключевых целей моего квеста - подражать провайдеру общего хостинга, связанному с разрешением файлов и владением. Мне бы очень хотелось, чтобы мне не приходилось учить пользователей необходимости менять такие вещи, чтобы увидеть их дополнения / изменения.

Chris_K
источник

Ответы:

15

Использование suexec и suphp обеспечивает разделение привилегий другого типа, чем по умолчанию.

По умолчанию пользователь отделяет разрешение от веб-сервера. То есть пользователю принадлежат файлы, и он должен предоставить веб-серверу разрешение на их просмотр и изменение.

Модель suexec / suphp заключается в том, что веб-сервер (при запуске сценариев) работает под учетной записью пользователя, поэтому у веб-сайта есть разрешение на все, что у него есть. В определенной степени это устраняет разделение между пользователем и веб-сервером, но взамен оно обеспечивает РАЗНОЕ разделение: то есть между веб-сайтом одного пользователя и веб-сайтом другого пользователя в одном и том же блоке.

По умолчанию PHP всегда запускается под учетной записью Apache, поэтому сценарии PHP одного веб-сайта могут обращаться к любым файлам, которые могут иметь сценарии PHP другого сайта. Следовательно, если одна учетная запись на сервере будет взломана, заражение может распространиться на другие. SuPHP предотвращает это.

Ни suexec, ни suphp не влияют на то, как apache обслуживает статический контент . Все старые правила все еще применяются. Вместо этого suexec и suphp изменяют учетную запись, под которой будут работать CGI и PHP (соответственно). Suexec запускает исполняемый файл CGI под учетной записью владельца, а SuPHP запускает сценарии PHP под учетной записью владельца.

Suexec и SuPHP не обязательно лучше . Они просто разные . Они не будут препятствовать взлому сайта (и, возможно, могут облегчить взлом сайта ), но предотвратят распространение компрометации на одном сайте на все остальные. Для администратора сайта эта изоляция, возможно, более важна, поэтому некоторые системы общего хостинга делают suexec и suphp по умолчанию.

Одна из наиболее распространенных «ошибок» заключается в том, что SuPHP проверяет владение и разрешения сценария перед его выполнением и возвращает ошибку 500, если разрешения не подходят.

Особенно:

  • Владелец и группа файла должны соответствовать владельцу сайта (как указано в конфигурации apache)
  • Файл не должен быть доступен для записи
  • Родительский каталог не должен быть доступен для записи
tylerl
источник
Итак, зная, что я хочу эмулировать модель общего хостинга (как вы указали, удерживая пользователей друг от друга), мне больше подходит модель suexec / suphp, или вы чувствуете, что есть лучшие варианты? Я также отредактировал этот пост, чтобы показать, что одной из его основных целей является недопущение обучения пользователей необходимости изменять права доступа к файлам или владельцев, чтобы просто увидеть их изменения или дополнения.
Chris_K
2
suexec / suphp - хорошее решение для того, что вам нужно.
Tylerl
Я бы предпочел suphp suexec. Думаю, безопаснее.
Владислав Раструсный
@FractalizeR: Обычно вы используете оба одновременно. SuPHP для PHP, suexec для CGI. Вы можете запустить PHP поверх suexec, запустив PHP как CGI, но это немного ненужно, поскольку существуют лучшие (более безопасные, более эффективные) опции для PHP.
Tylerl
@tylerl: Большое спасибо за ваш ответ. Какие наиболее безопасные / эффективные решения для PHP вы имеете в виду?
Бенджамин