Основное назначения модуля - помещение apache в chroot окружение сразу после выполнения первичных блоков инициализации, т.е. позволяет не копировать в chroot окружения необходимые  для работы apache и mod_php библиотеки, не создавать /dev, /etc/passwd и т.д. Достаточно подключить модуль, определить директивой ChrootDir корень и при необходимости создать программное окружение для выполнения CGI-скриптов.

URL: http://core.segfault.pl/~hobbit/mod_chroot/
Новость: http://www.opennet.me/opennews/art.shtml?num=3860

• Интересное ПО mod_chroot - упрощенный вариант помещения Apache в chroot,GRisha, 00:04 , 18-Май-04
  • Интересное ПО mod_chroot - упрощенный вариант помещения Apac...,choopie, 03:34 , 18-Май-04
• Интересное ПО: mod_chroot - упрощенный вариант помещения Apache в chroot,scorp21, 11:18 , 18-Май-04
• Интересное ПО: mod_chroot - упрощенный вариант помещения Apache в chroot,Paul, 11:20 , 18-Май-04
  • Интересное ПО: mod_chroot - упрощенный вариант помещения Apa...,Paul, 11:22 , 18-Май-04
  • Интересное ПО: mod_chroot - упрощенный вариант помещения Apa...,uldus, 14:10 , 18-Май-04
  • Интересное ПО: mod_chroot - упрощенный вариант помещения Apa...,Tedim, 08:57 , 16-Фев-06
• Интересное ПО: mod_chroot - упрощенный вариант помещения Apache в chroot,ant, 00:42 , 19-Май-04

как насчет suexec ?
надо создавать /etc/passwd в новом окружении ?

всяко...

Прикольно.
Я его портом даже сделал и послал через send-pr

Сомнительная польза от модуля. Изначально замкнутые программные среды создаются для того, чтобы в случае компрометации сервиса злоумышленник не получил доступа ко всей системе. Таким образом, идеология замкнутой программной среды подразумевает, что оная реализуется сторонними средствами, а не средствами самого сервиса. В данном случае, к примеру, при компрометации сервиса Apache, установленного в ЗПС средствами mod_chroot, злоумышленнику достаточно изменить директиву ChrootDir в конфигурации Apache и перезапустить сервис, чтобы получить доступ к требуемому корню ОС.

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

>изменить директиву ChrootDir в конфигурации Apache и перезапустить сервис, чтобы получить

Для перезапуска и изменения конфига взломщик уже должен обладать rootовыми прпавами. Как я понял mod_chroot тем и хорош, что дает возвожность вынести апачевские потроха во вне chroot'а. Для защиты php с его вечно проламливаемым safemode пойдет.

Должно быть весьма полезным в случае защиты от сайтов, исследующих сервер, например, содеращих сайт-файловый менеджер. Именно это я и ищу!

А еще mod_security умеет делать chroot таким же макаром