ПРОЕКТЫ 


  АРХИВ 


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: Re[3]: [apache-talk] dummy question2





On Sun, 3 Mar 2002, Khimenko Victor wrote:

>
> На самом деле я в отношении PHP уже не первый год пытаюсь понять: почему
> его нельзя собрать в виде FCGI-модуля со встроенным suexec'ом ? Это сразу
> решило бы все проблемы с safe_mode (в связи с ее отменой :-), а также с
> файлами, создавамыми из PHP-скриптов, а нагрузку увеличило бы крайне
> незначительно: лишний fork по сранению со временим интерпретирования
> скриптов - копейки. Где я неправ ?
>

Да - если не хочется заставлять людей использовать FCGI, то можно suexec
встроить в mod_php ! По той же схеме, что и обычный suexec примерно: до
того, как apache лишил себя прав root'в взять из /dev/random байт 16
seed'а, fork'нуть процесс php_suexec и создать socket для общения с детьми
apache'а. При обработке запроса проверить (по известным правилам) нужен
suexec или не нужен и если нужен, то засунуть запрос (подтвержденный seed'ом)
в socket и получить оттуда же ответ. php_suexec сделает те же проверки,
что и обычный suexec (плюс проверка seed'а), fork'нет ребенка с нужным
uid'ом/gid'ом и этот ребенок выполнит скрипт. При таком подходе, правда,
PHP будет снова и снова разбирать скрипты, то есть потеряется не
только время на fork, но и сам PHP будет работать медленнее, но во
многих случаях и это приемлемо: в конце концов PHP 3.x всегда так работал...
Работы не на полчаса, конечно, не и не rocket science ...

> On Sun, 3 Mar 2002 konsul@ratel.ru wrote:
>
> > Hello Дмитрий,
> >
> > Sunday, March 03, 2002, 1:25:15 PM, you wrote:
> >
> > >>> получается, что даже в тандеме с suexec избавится от хождения скриптов
> > >>> по чужим хомяка нельзя?
> > >>>
> >
> > KV>> ЛЕГКО! Если думать головой, разумеется :-) Права должны быть 2750, 
>группа
> > KV>> должна быть apache и все: скрипты пользователя могут читать/писать (они
> > KV>> владеют и файлами и каталогами), apache может читать (он в группе), 
>больше
> > KV>> никто туда не попадает...
> >
> > Д> Но, тады получится, что PHP (mod_php) все равно смогут лазить по чужим
> > Д> директориям, ибо они работают от имени apache?
> >
> > спустя полчаса после победы suexec, столкнулся с этой-же проблемой ;)
> > к счастью выяснилось что не всё так плохо. путём ограничений
> > safe_mode, можно запретить лазить скриптам одного овнера, по файлам
> > другого. оно напишет 'safe mode restricted' и выругается на разные
> > uid. одна беда, все файлы создаваемые скриптами имеют одного овнера и
> > одну группу, и в принципе чужой скриптяра может по ним полазить. для
> > начала правда придётся узнать полный путь до этого файла :) с таким
> > раскладом еще как-то можно мирится.
> >
> >
> >
> > --
> > Best regards,
> >  konsul                            mailto:konsul@ratel.ru
> >
> > 
>=============================================================================
> > =               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                 
>=
> >
>
> =============================================================================
> =               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                 =
>

=============================================================================
=               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.