Кто сталкивался с необходимостью загнать апач в chroot окружение, тот меня поймет. Если использовать системные средства (chroot, jail), то гемороя ровно в два раза больше, нежели при использовании SecChrootDir (директива mod_security). Убедился на собственном опыте c Apache 1.37.*. Но времена первого апача уходят и возникла необходимость перехода на Apache 2.2.* с которым проблем оказалось больше. Устанавливаем апач, устанавливаем mod_security, конфигурируем. Стартуем апач, смотрим localhost и видим It's work! Всё замечательно, но: Кто сталкивался??? Если надо конфиги - выложу.
>>[Tue Nov 27 17:41:15 2007] [crit] (2)No such file or directory: mod_rewrite: could not init rewrite log lock in child я так понимаю модуль сообщает о невозможности записи в лог файл. почему так происходит? >>для ясности скажу что /usr/local/etc/apache22 есть симлинк на /chroot/apache/usr/local/etc/apache22 судя по ошибкам мне кажется ты сделал ровно наоборот тем не менее, делать символическую ссылку из недоступного, после chroot, каталога в новый нелепо. симлинк это всего лишь файл с именем файла на который он ссылается и атрибутом того, что он не есть непосредственный файл, а симлинк поэтому каталог так же будет недоступен: если уж и делать, то жесткую ссылку (man ln). только вроде на каталог ее сделать не удастся.. вообще тут достаточно проблем, связанных с ограничением апача, например мне будет интересно знать как ты будешь с таким апачем запускать скрипты и тд ну не считая тупой установки всего в /chroot зачем тебе апач так "запирать"?
Интуиция?? =) Скажу больше, если rewrite_module ZaCoмментировать то ошибка исчезает. Как от неё избавиться?? Где под встроенный rewrite_module узнать о директивах, касаемо файла лога?? Аналогично с SSL. Тут самое интересное) Если апач так не "запереть", то получим практически свободный серф по файловой системе сервера с правами на чтение (FreeBSD в данном случае, права по умолчанию при установке на большинстве файлов 755) средствами PHP + дополнительная защита от разного рода ошибок в функциях PHP и проч. В OpenBSD Apache по умолчанию загоняется в chroot окружение, но OpenBSD не решает ряд других задач связанных с маршрутизацией трафика. Все скрипты прекрасно себя чувствуют. Установка всего в /chroot на самом деле далеко не тупая.. Использование именно chroot это однозначно гемморой, поэтому mod_security рулит. А в чем разница??? А разница в том что при chroot [что] [в какой папке] необходимо иметь подобие системы в /chroot (очеень много гемора с /dev /var/run, passwd и прочими основными системными файлами/папками..), а mod_security требуются лишь основные бинарники и собственно данные. Ну я не знаю как тебе доказать что это работающий симлинк =) Более того, ee /usr/local/etc/apache22/httpd.conf тоже работает Так что man ln не ко мне ln -s [куда] [откуда] Специфика такая.. Для запуска использую симлинк, чтобы апач запускался уже в чрут-окружении, то есть мне даже /rc.d/apache22 по идее не надо править. И ничего нет плохого в том, что два или более пути ведут в одно место. То что из чрута просится в /usr/local/etc/apache22 и то что из реальной системы просится туда же попадают в одно место. Гланое чтобы в обратную сторону такого эффекта не было Симлинк для того и сделан чтобы не было конфликтов. Подчеркиваю, что вся эта связка с первым апачем себя прекрасно чувствовала и работала без каких-либо нареканий.
>>Скажу больше, если rewrite_module ZaCoмментировать то ошибка исчезает. Как от неё избавиться?? ну наверное он не может сделать вызов flock на файл логов, тк файла нет) путь к файлу задается через rewritelog. про ссл в гугле посмотри, я думаю аналогично >>Тут самое интересное) Если апач так не "запереть", то получим практически >>свободный серф по файловой системе сервера с правами на чтение (FreeBSD в >>данном случае, права по умолчанию при установке на большинстве файлов 755) а чего? это архитектура системы такая. очень мало людей пока жалуются на такую в общем случае неполноценную систему прав, хотя конечно было бы удобно если в следующих дистрибутивах как линукс, так и бсд включали нечто вроде selinux. в твоем случае, если хочется делать супербезопасный веб-сервер задача сводится к извращенному построению ОС со своими правами уровня апача, а точнее процесса апача, а учитывая то, что на это способен только рут (ну по-хорошему естественно, я про setuid, setgid) так выгибаться не стоит. >>Установка всего в /chroot на самом деле далеко не тупая.. я не говорил о бездумности решения загонять апач в чрут, наоборот. я имел ввиду, что, например, если у тебя в планах поддерживать cgi, то тебе придется устанавливать все с --prefix=/chroot/usr/local ну это то еще ладно, а если приложению потребуется вызов внешней утилиты? ясное дело копировать bin глупо, потому что чему-нибудь понадобиться что-нибудь и из lib каталога, короче говоря, так можно проще сделать cp -R * /chroot только это совсем нелепый вариант так я и спрашиваю, как ты собираешься после чрут организовавыть доступ к тому что было? а не проще ли вообще в чрут не загонять? хотя естественно, если цги не требуется это почти не нужно.. для пхп-сайта чрут лучшее решение однозначно, только не забудь ln /tmp/mysql.socket /chroot/tmp /chroot/var/log имеется? >>Ну я не знаю как тебе доказать что это работающий симлинк =) да нет, я просто подумал что в чруте у тебя симлинк на /usr/local/etc/apache22) >>Так что man ln не ко мне ln -s [куда] [откуда] гг наоборот >>Подчеркиваю, что вся эта связка с первым апачем себя прекрасно чувствовала и работала без каких-либо нареканий. если у тебя посещаемость не вот какая огромная, то оставь первый..
Конечно оно было найдено. Опытным путем выяснилось что Апач 2.2 имеет совсем другую модель инициализации модулей. Значит по текстам ошибок.. Это от лукавого как говорится =) Просто модуль SSL инициализируется, а инициализировать и нечего.. Там ряд параметров идут вне <IfModule>.. Решилось просто настройкой SSL для Apache 2.2.* То что после скрипта получилось (4 файла) делаем cp server.* /usr/local/etc/apache22; chmod 400 /usr/local/etc/apache22/server.* Теперь ee /usr/local/etc/apache22/httpd.conf Ищем строчку с httpd-ssl.conf и раскоментируем. Всё отлично.. Там по умолчанию все пути под нашу картину заточены. Единственное, в etra/httpd-ssl.conf можно по желанию определить действие на запрос ввода PASSPHRASE. 100% работает на FreeBSD 6.2. А мне Егорыч+++ на канале рассказывал про cd /usr/ports/www/apache22; make secure; =) Это на первом апаче было или даже для порта Apache-SSL Не суть =) Едем дальше. Это самое западло... Также опытным путем было выяснено что ошибка генерируется собственно mod_security.. Снос соответствующих директив не помог из чего сделан вывод о несовместимости заявленного функционала mod_security с Apache 2.2.6. Как я могу запихнуть через mod_security всё в чрут окружение, если он сам там работать не может?? =) Снёс пока что, хотя штука хорошая.. Обязательно вернусь к этой теме в статьях На тот момент основной задач было загнать всё в чрут.. mod_security не спас, системный chroot также отказался всё это приютить.. Очередь дошла до mod_chroot найденного в портах cd /usr/ports; make search name=chroot; Вот так и познакомились =) Поставил, с опытом предыдущих ошибок всё заработало быстро... Осталась лишь: Тут долго парился.. Очевидно что проблема во встроенном модуле rewrite. Начал играться с директивами RewriteLog, RewriteLogLevel.. Даже когда явно указываешь что не нужен тебе лог, он всё равно его делает... Самое интересное, что создает он его вне чрут окружения, а потом ищет в чрут окружении.. Кончилось всё правкой исходного кода =) Модуль реально не понимает RewriteLogLevel 0, это очевидный баг, ибо порты обновил (можно зарелизить от имени АНТИЧАТА кому интересно , поэтому Ну или как вам там удобно.. Комментируем строчки которые генерят ошибку и собственно функцию её вызывающую (файл большой, ищем по тексту ошибки) Code: #ifndef REWRITELOG_DISABLED /* PATCHED WITH ANTICHAT POWER HERE rv = apr_global_mutex_child_init(&rewrite_log_lock, NULL, p); if (rv != APR_SUCCESS) { ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s, "mod_rewrite: could not init rewrite log lock in child"); } THEN CONTINUE */ #endif Далее если апач ещё не был установлен make install, а если трабла уже на руках, то make deinstall; make reinstall; Вот и всё. Имею чрут, всё работает, и хакеры целые и сервер доволен PS. В асю прислали: - Что тяжелее - килограмм земляники или килограмм гвоздей? - Тяжелее будет высрать гвозди (с)sql.ru
