ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] mod_perl suid'ный



In <199903201130.OAA00173@amsoft.ru> Andrew Maltsev (am@amsoft.ru) wrote:
AM> Начал изучать mod_perl и вот какой чайниковский вопрос - а как
AM> собственно дать скрипту права читать/писать файлы некоего
AM> пользователя?

Краткий ответ (поражающий своей простотой :-) : НИКАК.

Развернутый ответ: вся идея mod_perl'а заключается в том, чтобы избежать
лишних запусков интерпретатора perl'а и fork'ов. Однако это обозначает,
что скрипты исполняются как часть процесса httpd ! И имеют соответствующие
права (обычно -- парва пользователя apache или nobody). Это ограничивается
структорой *NIX'а, которая родилась не на пустом месте: НЕЛЬЗЯ допускать,
чтобы программа меняла EUID после того, как она выполняла неизвестный код
(вспомните про perl DSO хотя бы ! да и сам perl я бы не сказал, чтобы был
готов к исполнению с правами root'а). Что можно сделать ? Только две вещи:
  а) пускать [копию] apache из под нужного пользователя
  б) обеспечивать выполнение скриптов/запросов скриптов внешней программой
     (suidperl, suexec, etc).

Возможности и недостатки обоих способов, я надеюсь, очевидны, но третьего не
дано... Можно порекомендовать fastcgi и suidperl или другие подобные решения...



=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.