The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Модифицированный Apache с разделением привилегий для виртуальных хостов

02.04.2007 09:28

dkLab Apache - это дистрибутив для тех, кто собирается использовать Apache в Unix для обслуживания нескольких полностью независимых друг от друга сайтов, работающих под разными, полностью разграниченными друг от друга пользователями Unix.

По сути это Apache 1.3.34, на который наложены некоторые "самодельные" патчи. Вот функциональность, которую они добавляют:

  • Запуск различных виртуальных хостов под различными Unix-пользователями. То, под каким пользователем работает виртуальный хост, задается в его стандартных директивах User и Group. Все скрипты, включая скрипты для mod_php, CGI и т. д., работают с правами указанного пользователя и группы и не могут получить доступ к файлам другого виртуального хоста. Долой safe_mode и проблемы с правами доступа в PHP!
  • Возможность создавать виртуальные хосты по шаблону: ABC.example.com -> /home/example/ABC. Вы можете ссылаться в директиве DocumentRoot на нужную часть доменного имени, например, так: /home/example/$-3+ (в данном примере это будет /home/example/ABC). Просто создайте директорию, чтобы добавить на сайт новый поддомен!
  • Модуль mod_rewrite защищен от любого рода "зацикливаний". Неосторожно или злонамеренно написанные директивы в .htaccess не могут "подвесить" весь сервер.

    1. Главная ссылка к новости (http://dklab.ru/lib/dklab_apac...)
    Автор новости: Дмитрий Котеров
    Тип: К сведению
    Короткая ссылка: https://opennet.ru/10329-apache
    Ключевые слова: apache, patch, suexec, virtual, mod_rewrite
    При перепечатке указание ссылки на opennet.ru обязательно
    Обсуждение (34) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Salvator (?), 09:55, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Может, туплю с утра, но разве такой функционал не дают стандартные средства апача? suexec + vhost_alias ...
     
     
  • 2.3, andrew (??), 10:15, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, тупишь. Как ты через suexec прикрутишь mod_php?
     

  • 1.2, eSupport.org.ru (?), 10:06, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    mod_php не дает стандартные средства.
     
  • 1.4, Phil Kulin (?), 10:24, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Скажи мне дорогой друг, я правильно понимаю, что предложенный вариант отличается твоего же от варианта пятилетней давности наличием некоего нового аналога mod_vhost_alias (я, кстати, не понимаю, почему ещё никто этого не сделал :) и тем, что keepalive теперь принимаются? Если это так, я сейчас твой roadmap раскритикую. Я ещё когда честно украл по ещё не убитым ссылкам на тот древний вариант алгоритм работы имел много чего сказать :)
     
     
  • 2.13, Дмитрий Котеров (?), 12:19, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, неправильно. Отличия от варианта пятилетней давности:
    1. Используется стандартный fork, а не vfork/rfork. Т.е. память не шарится между ребенком и родителем => секьюрность не хромает (невозможно даже через переполнение буфера влезть в рутового родителя). Кроме того, лучшая совместимость с не-Линуксами.
    2. Порождение потомков происходит асинхронно, что значительно ускоряет обработку запросов - делает ее более "гладкой", т.к. апач сам умеет следить за тем, чтобы в наличии всегда находилось несколько "свободных" апачей.
    3. Даже этот асинхронный fork делается не на каждый запрос, а на каждое соединение - для типовых случаев это в 5-10 раз быстрее (по числу картинок на средней странице).
    4. Нету дыры в безопасности с register_shutdown_function в mod_php, которая была в патче пятилетней давности (из-за которой этот патч и был убран, собственно). Ее там даже чисто теоретически быть не может.
     
     
  • 3.15, Phil Kulin (?), 12:50, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    1. Это я понял.
    2. А можно чуток подробнее про асинхронные форки? (не хочу в код лезть без пояснений).

    Я чего хотел сказать... Некоторая проблема есть с fork(). Конечно, fork() (как и пять лет назад) делается действительно странно и забавно, но практика показывает, что в нашем случае это помогает слабо. Не знаю как в твоей практике, а я с форком так и не смог заставить работать адекватно apache. 15qps для него предел, на котором он начинает заниматься самодиспетчеризацией. KeepAlive вроде даже и действительно сильно помог бы... но пять лет назад. При том, что сейчас чуть ли не большинство посетителей сайтов - роботы поисковиков... все ли они этот самый keepalive держат? Тоже самое с акселераторами - весь смысл keepalive на уровне apache пропадает при наличии того же nginx.

    Я много думал на эту тему. Единственный хороший универсальный вариант, который я вижу - писать свой MPM, который работать примерно как perchild, но при этом держать в запасе только те процессы, к которым часто обращаются. Туда же можно воткнуть систему всяких ренайсов и т.п. Но пока я думал, хостинг как отрасль повернулась на путь в небытие - когда я додумаю, слово "хостинг" будет странным понятием из прошлого, а в индивидуальном порядке это всё не нужно :) Опоздал.

     
     
  • 4.20, Michael Shigorin (?), 17:22, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Тоже самое с акселераторами - весь смысл keepalive на
    >уровне apache пропадает при наличии того же nginx.
    А высказанные соображения касательно предела касаются одного apache?

    >когда я додумаю, слово "хостинг" будет странным понятием из прошлого
    В смысле виртуальный?

    Я почему спрашиваю (c) Печкин: с одной стороны, поддерживаю apache-1.3 в ALT Linux, с другой -- весной выходит серверный 4.0, в пререлизах которого ovz VE делаются из веб-морды.

     
     
  • 5.27, Phil Kulin (?), 20:38, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>Тоже самое с акселераторами - весь смысл keepalive на
    >>уровне apache пропадает при наличии того же nginx.
    >А высказанные соображения касательно предела касаются одного apache?

    Хм? Ну да. Один апач на одном сервере. Целерончик что ли у меня тогда был 2.4GHz...

    >>когда я додумаю, слово "хостинг" будет странным понятием из прошлого
    >В смысле виртуальный?

    Да. Он уже есть "паровой автомобиль", просто люди ещё об этом не знают.

     
  • 4.22, Дмитрий Котеров (?), 20:06, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    При наличии nginx также практически пропадает вероятность, что вы - хостер, а не отдельный крупный проект с единственным пользователем httpd, которому и стандартного апача вполне достаточно. :-)
     
     
  • 5.24, Michael Shigorin (?), 20:16, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >При наличии nginx также практически пропадает вероятность, что вы - хостер, а
    >не отдельный крупный проект с единственным пользователем httpd, которому и стандартного
    >апача вполне достаточно. :-)
    Ну почему, я вот -- хостер (специфический -- бесплатно хостим проекты free software), и существованию/работе nginx очень даже рад. ;-)
     
  • 5.25, Phil Kulin (?), 20:32, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >  При наличии nginx также практически пропадает вероятность, что вы - хостер

    Мда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука на непредсказуемых нагрузках.

     
     
  • 6.30, eSupport.org.ru (?), 08:20, 03/04/2007 [^] [^^] [^^^] [ответить]  
  • +/

    >Мда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге
    >nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука
    >на непредсказуемых нагрузках.


    Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох, целуйте фикус и поливайте бабушку :)

     
     
  • 7.31, Phil Kulin (?), 10:26, 03/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>Мда? :) Странно, был в top10 виртуальных хостеров, когда на всём хостинге
    >>nginx внедрил... Он сейчас акселератором у большинства стоит. Зело полезная штука
    >>на непредсказуемых нагрузках.
    >Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох, целуйте фикус и
    >поливайте бабушку :)

    Да и замечательно. Это намного лучше, чем демонстрация не имеющих художественной ценности песочных часов. Это 5xx-фобия меня всегда удивляла. Чёткая ошибка против неясного ожидания...

     
  • 7.32, Michael Shigorin (?), 11:35, 03/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Ага. И гордо демонстрирует 50x'ую ошибку - апстрим сдох
    А нектррые, междпррочим, ещё и monit выписывают... :)
     
  • 3.19, вуглускр (?), 16:29, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Нет, неправильно. Отличия от варианта пятилетней давности:
    >1. Используется стандартный fork, а не vfork/rfork. Т.е. память не шарится между ребенком и родителем => секьюрность не хромает (невозможно даже через переполнение буфера влезть в рутового родителя). Кроме того, лучшая совместимость с не-Линуксами.
    Означает ли это что он памяти жрет еще больше чем просто апач? Ж8-О
     
     
  • 4.21, Дмитрий Котеров (?), 20:03, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Читайте маны по fork, ключевые слова "copy on write".
     

  • 1.5, Аноним (-), 10:31, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://packages.debian.org/unstable/net/apache2-mpm-itk
     
     
  • 2.6, Phil Kulin (?), 10:37, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Очень внушительное хорошее и подробное описание...
     

  • 1.7, winamp (?), 10:46, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    действительно, а чем это лучше, чем apache2 с mpm-itk?
     
     
  • 2.14, Дмитрий Котеров (?), 12:37, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    То, что сразу бросается в глаза в исходниках, - mpm-itk создает дочерние процессы синхронно, а dkLab Apache - асинхронно (впрочем, первый можно доработать так, чтобы он тоже создавал детей асинхронно). Возможно, есть и другие существенные отличия, я не знаю. Если кто-то увидит - пишите сюда.
     
     
  • 3.16, гость (?), 13:16, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >То, что сразу бросается в глаза в исходниках, - mpm-itk создает дочерние
    >процессы синхронно, а dkLab Apache - асинхронно (впрочем, первый можно доработать
    >так, чтобы он тоже создавал детей асинхронно). Возможно, есть и другие
    >существенные отличия, я не знаю. Если кто-то увидит - пишите сюда.
    >

    Как обстоят дела с модулем user_dir, который "управляет" домашними каталогами владеьцев?
    Коих (владельцев) может быть гораздо больше чем вирт.хостов.

    Как обстоят дела владельцами, которые не пользователи данной юникс-системы, а например из LDAP?

     

  • 1.8, _Kuzmich (??), 11:17, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Спасибо за mpm-itk, буде пробовать.
     
  • 1.9, аноним (?), 11:36, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    mpm-itk тормозит, что не намного лучше простого cgi.
    fastcgi выигрывает в пару раз
     
     
  • 2.10, Аноним (-), 11:54, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >mpm-itk тормозит, что не намного лучше простого cgi.
    >fastcgi выигрывает в пару раз

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

    Как я понял dkLab патч заставляет дочерние процессы обрабатывать запрос работая под root. Нет в жизни счастья.

     
     
  • 3.11, Phil Kulin (?), 12:06, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Под root работает только начальная дочка. Обработка уже идёт под пользователем. Не вижу ничего страшного. Основной процесс апача тоже под root работает и никого это не пугает. Естественно, есть небольшое отличие в том, что здесь владелец назначается динамически, но несколько проверок в код дают определённую уверенность.
     
     
  • 4.12, q (??), 12:12, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем под рутом?
    Достаточно под рутом открыть сокеты 80 и 443 и потом понизить привилегии, chroot, fork, и новые непривилегированные дочерние процессы. Тогда вообще не будет рутовских процессов (только на момент запуска)
     
  • 4.17, si (?), 14:18, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    главная опасность это разбор заголовков под рутом, если тут ошибиться можно получить remote root.
     
     
  • 5.26, Phil Kulin (?), 20:35, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >главная опасность это разбор заголовков под рутом, если тут ошибиться можно получить
    >remote root.

    Не давайте рута ни при каких обстоятельствах. Все карты в руках - перед setuid проверяйте на кого setuid делаете.

     
     
  • 6.28, si (?), 22:34, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    причем ту давайте/ не давайте, я несколько о другом

    тот child который разбирает заголовки, ищет какой это vh и делает set*id() работает под рутом. заголовки он получает от клиента, следовательно если будет ошибка в коде разбора заголовков, то потенциально удаленно можно получить рута. кстати упомянутый вами master процесс иметь от рута вполне безопасно потому что он с внешним миром никак не связал и удаленно его уронить намного сложнее.

     

  • 1.18, FatBastard (?), 16:00, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а чем это отличается от mod_suid?
     
     
  • 2.23, Дмитрий Котеров (?), 20:08, 02/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что не нужно ставить модуль ядра. А также тем, что не нужно молиться, чтобы какое-нибудь переполнение буфера в mod_php не заставило выполниться setuid-функции.
     

  • 1.29, sargio (ok), 23:39, 02/04/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А может еще добавить что-нить вроде DocumentChroot или нафиг оно?
     
     
  • 2.33, Дмитрий Котеров (?), 13:12, 03/04/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Я считаю, что "нафиг оно". Потому что замучаешься для chroot-а окружение готовить и потом за ним следить. В него же должны войти все утилиты хостинга - perl там, python и т.д. А разделение прав на уровне пользователей в Unix и так работает прилично, без всякого chroot-а.

    Что касается виртуального хостинга - я вот тоже последние несколько лет думал, что это "паровая машина", которая скоро канет в лету (потому и не публиковал патч, в частности). Но больной все еще скорее жив, чем мертв, и в ближайшие годы я не вижу, чтобы тенденция серьезно изменилась.

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

     
     
  • 3.34, Gregory Veritikov (?), 09:24, 31/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    > Что касается виртуального хостинга - я вот тоже последние несколько лет думал,
    > что это "паровая машина", которая скоро канет в лету

    все это реально, вот делают же nginxhosting.com

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру