In <005401bfab64$6d30feb0$390710ac@rtsnet.ru> Denis Blinov (blinov@rtsnet.ru)
wrote:
DB> Привет
>> DB> Единственное, что приходит в голову - suid'ная программка,
DB> принадлежащая
>> DB> руту, принимающая от перлового скрипта данные и, прикинувшись нужным
DB> нам
>> DB> юзером, осуществляющая все файловые операции.
>> DB> Судя по архивам, с год назад тут нечто подобное обсуждалось. Ничего
>> DB> разумного тогда придумать не удалось?
>> 4) вы ДЕЙСТВИТЕЛЬНО этого хотите ? тогда пускайте свой apache из под
DB> root'а
>> и все файлы создавайте под ним же - по степени разрушительности это
DB> близкое
>> действие...
DB> Не, я этого не хочу ;) потому и не пускаю апача из-под рута, а пытаюсь
DB> придумать какое-то внешнее приложение.
:-))
>>
>> P.S. Да, как несложно заметить из вышеописанного, этот самый suid'ный
DB> бинарник
>> НИ В КОЕМ СЛУЧАЕ не должен абсолютно доверять тому, что его вызывает
DB> легальный
>> скрипт; в худшем случае нужно реализовать набор проверок a-la suexec, но
DB> лучше
>> всего вынести авторизацию в него...
DB> Вот собственно об этом и был мой вопрос - как это лучше организовать. Либо
DB> скрипт передает
DB> нашему бинарнику представленные юзером логин и пароль, а тот каждый раз
DB> бегат в tacacs и проверят (долго небось это будет очень?).
Нет. Не будет долго. Снявши голову по волосам не плачут: по сранению с exec'ом
обращение к tacacs'у - копейки. Если же эти скрипты будут дергаться часто, то
все равно придется переходить на FastCGI какой-нибудь... Конечно если
пользователей немного... Если пользователей много и все их скрипты часто
дергаются - "you are out of luck"...
DB> Или можно давать бинарнику номер тикета (Apache::TicketAcess все равно
DB> будет использоваться для идентификации клиента самим скриптом), чтобы тот
DB> его проверял на валидность.
Проблема не только (и не столько) в паролях. Нужно, чтобы через этот канал не
было снесено ничего лишнего (например не принимать от скрипта имя файла, в
который писать или хотя бы сделать несколько проверок). Если человек взломал
сервер, то он и билет (ticket) передаст и пароль с именем пользователя смогет
и все снести сможет (когда пользователь с следующий раз зайдет) - тут уж ничего
не поделаешь. Но желательно, чтобы он даже в этом случае смог испортить только
то, что легальные пользователи в порыве бешенства могут испортить, а не
уничтожить все файлы пользователя (*nix'а, не твоей web-based program :-) и
(в переделе) систему в клочья разнести :-) С этой точки зрения, наверное, билет
даже лучше. Только не передавай его через command line или environment :-)
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
