Ну изначально Вы говорили, что shell - дыра в безопасности, отсюда все и растет, а по сути что cgi что shell - разницы _практически_ никакой, только в первом случае работать куда удобнее, по крайней мере продвинотому клиенту, а если кто-то серьезно решил сломать систему, то ему все равно что есть cgi или shell.
у Seliger тоже иногда не все в порядке ...
например сессии, зааплоаженные файлы удалить. Вся это возня с выставлением соответствующих прав в случае с mod_php по сути одна большая дыра, например разрешили куда-либо писать апачу, соответственно туда злоумышленник может свой код залить, и дело тут не в том что кого-либо сломают через phpbb (тут уж клиент сам себе злобный буратино), а в том, что от этого могут пострадать другие сайты, расположенные на сервере.
Угу, может кто-нибудь подскажет как привлечь-то ?
Гм, sshd запустить не выйдет по двум причинам:
1. у Вас прав к /etc/shadow нет, чтобы пароли сравнивать.
2. никто Вам без прав рута tty не откроет.
единственный способ запускать на нервивелегированном порту bash -i, только это с успехом закрывается файерволом.
разница между cgi и shell отличается только в наличии контролирующего терминала в последнем, то есть если существует какой-либо exploit позволяющий запустить рутовый shell, то в первом случае он не запустится, правда это не меняет положения дел, всегда можно заменить в shellcode вызов /bin/sh на что-нибудь другое. Про .bash_history не совсем правда, можно просто сделать export HISTFILE=/dev/null, и тогда никакие логи оставаться в истории не будут, можно конечно сделать restricted shell и пр, но тогда возникает такой вопрос: а нужен ли кому такой shell ?
про почту как всегда яндекс:
http://earnforum.com/vb/printthread.php?threadid=33224
http://www.hostinfo.ru/forum/posting.php?mode=topicreview&t=254&sid=5dd836feb59cf93ce8147d77d757b7e3
http://fotonovosti.ru/forum/posting.php?mode=quote&p=324&sid=d13acde157421e050ae0e368869c37b1
с mod_php много у кого возникают проблемы, точнее она одна но большая, как известно php-скрипты запускаются из-под apache и не из-под обычного пользователя, соответсвенно вот что получается:
1. файлы созданные при помощи скриптов нельзя удалить/изменить через shell/ftp, поскольку у файлов стоит оунер apache, это конечно решается некоторыми способами (например выставлять в скриптах umask, самому в скриптах дописывать chmod, но тогда клиенту приходится уже самому ковыряться; или например вот солюшн от .m: http://masterhost.ru/support/doc/php/#compile , только при этом теряется скорость и некоторые вкусности)
2. по соображениям безопасности в php приходится отключать ряд функций (конкретно весь класс exec-функций, плюс еще некоторые, в том же .m это написано: http://masterhost.ru/support/doc/php/#limitations) после чего некоторые бесплатные движки перестают работать.
вроде тут все разжевано про апач: http://phpclub.ru/talk/showthread.php?threadid=47772&rand=92
Еще раз повторюсь, мы сейчас даже не задумывается о таких масштабах как .m. Вопрос не в том как стать такими же как .m, а в том, какой должен быть необходимый минимум чтобы клиент пошел к нам.
опыт 5 лет.
отсутствием проблем с почтой, отсутсвием проблем с php, если нужно про qmail и mod_php могу подробно изложить свое мнение. К тому же, мы не ориентируемся на .m, на начальном этапе нам не нужны тысячи клиентов, тут бы до сотни не плохо было бы дотянуть.
про ляпы, если можно поподорбнее расскажите :)
Если честно, я принципиальной разницы между разрешением запуска cgi-скриптов и предоставлением shell не вижу, в конце концов, можно немного поправить sshd, чтобы все вводимые команды логировались.
ну почему-же, есть _ненагруженный_ сервер, пара человек, некисло знающих апач и пару языков, которые по началу будут выполнять функции саппорта. А что можно предложить кроме стандартных сервисов (http, smtp, pop, imap, dns, ftp) ?
думаю, нам излишнии навороты типа уснавки форумов из панели и пр. не нужны, вполне будет достаточно управления почтой, dns и виртуал хостов, для всего остального у клиента будет шелл.
