>Безопаснее?! Вы шутите. Схема с меньшим числом компонентов, как правило, будет не
>только проще, но и надежнее и безопаснее. Вы же предлагаете один
>компонент, vsftpd, заменить на ЧЕТЫРЕ - апач, интерпретатор PHP, приложение на
>PHP, самописные костыли админа в кроне и пр. (кто сказал, что
>он тут не наляпает?). Наглядная иллюстрация: идёте, скажем, на Секунию, и
>считаете количество дырок за историю продукта - вот у vsftpd только
>одна, а у одного лишь интерпретатора PHP было более 300 (http://secunia.com/advisories/vendor/24/
>и просуммируйте). Именно так уважаемая и предлагает) Главное лишь - найти заказчика, и она такооооой проект реализует (с) Уж простите за сарказм)
>[оверквотинг удален]
>на веб-решение с жутко кривым дизайном и таким количеством дыр в
>реализациях. Сравнение будет в пользу FTP даже с учетом всех его
>исторических проблем - главные из которых, кстати, говоря, это использование символов
>Telnet "Interrupt Process" и Telnet "Synch" и неуказание кодировок (что, впрочем,
>уже давно лечится поддержкой UTF-8 по RFC 2640) плюс отсутствие стандарта
>на формат листинга каталога - но вовсе не поносимые тут вторичные
>коннекты. Их любой приличный NAT давно умеет, не говоря уже о
>том, что "проблема дизайна" здесь вопрос философский - IPv6 никакого NAT
>не предусматривает, считая именно его проблемой дизайна, а не требование свободного
>connectivity у протоколов.
Кстати, коль разработчик не дописал кусок кода (в vsftpd), отвечающий за кодировку то всегда найдется _русский_программер_ которому это не будет давать жить спокойно, и он допишет сам. Что и было довольно не плохо сделано в русском не официальном зеркале vsftpd.
Если уважаемую беспокоит не-секурность канала передачи данных, то пожалуйста, всегда можно прикрутить ssl, ключи под каждого клиента, список ip с которых разрешен доступ для данного конкретного клиента и многое-многое другое. Было бы желание.
