Linux.by

Как запретить запуск php отовсюду, кроме определенного каталога (и его подкаталогов) ?

для этого каталога прописать в конфиге апача:
<Directory /xxx/xxx/xx>
AddType application/x-httpd-php .php .php4 xxx
</Directory>
и убрать эту директиву из конфига главного сервера если она там есть
(все это для php в виде модуля апач)

По-разному можно. В том числе так, как предложили

Небольшой совет - не забывай про то, что в .htaccess,
лежащем в нужном каталоге, юзер может часть установок переопределить, в т.ч., те, которые связаны с php.

Invox писал(а):По-разному можно. В том числе так, как предложили

Небольшой совет - не забывай про то, что в .htaccess,
лежащем в нужном каталоге, юзер может часть установок переопределить, в т.ч., те, которые связаны с php.

Мда... Про <Direcotory> мог бы и сам догадаться... Тогда можно ли отрубить юзверю .htaccess как-то???

отрубить - можно

mend0za писал(а):отрубить - можно

Как это сделать или где про это прочитать?

отныне и надолго - твоим любимым сайтом станет http://httpd.apache.org/docs
если конечно не передумал хостинговать

mend0za писал(а):отныне и надолго - твоим любимым сайтом станет http://httpd.apache.org/docs
если конечно не передумал хостинговать

Не передумал..

AllowOverride None

Invox писал(а):По-разному можно. В том числе так, как предложили

Небольшой совет - не забывай про то, что в .htaccess,
лежащем в нужном каталоге, юзер может часть установок переопределить, в т.ч., те, которые связаны с php.

И кто ему разрешит?

И кто ему разрешит?

Это очень негуманно по отношению к клиенту.
Через .htaccess можно настроить много приятных штучек, не обращаясь в техсуппорт по каждой мелочи - паролирование, обработка ошибок, etc

Invox писал(а):

И кто ему разрешит?

Это очень негуманно по отношению к клиенту.
Через .htaccess можно настроить много приятных штучек, не обращаясь в техсуппорт по каждой мелочи - паролирование, обработка ошибок, etc

Ок, насколько вредным может быть разрешение .htaccess

Invox писал(а):

И кто ему разрешит?

Это очень негуманно по отношению к клиенту.
Через .htaccess можно настроить много приятных штучек, не обращаясь в техсуппорт по каждой мелочи - паролирование, обработка ошибок, etc

Не к клиенту, а потенциальному злоумышленнику, который купил у меня хостинг с целью...

1.положить мой сервер
2.уничтожить или украсть данные соседей
3.рассылать спам с моего сервера
4.использовать то, за что не заплатил
5.злоупотребить каналом
6.и хуже

Так что максимум, на что может надеятся -

AllowOverride AuthConfig FileInfo Indexes Limit

И хватит.
Самоубийственно позволить использовать Options или All

b0rmann писал(а):

Invox писал(а): Это очень негуманно по отношению к клиенту.

Не к клиенту, а потенциальному злоумышленнику

Паранойя хороша, когда в меру

Нельзя ожидать, что все клиенты будут белыми и пушистыми.
Но нельзя и напрягать излишними ограничениями, не позволяя ничего делать.
Наличие компромисов и доброжелательность привлекает клиентов.

b0rmann писал(а): 1.положить мой сервер
2.уничтожить или украсть данные соседей
3.рассылать спам с моего сервера
4.использовать то, за что не заплатил

Нет никакой гарантии того, чтобы уберечься от подобного.
Если уж есть у кого-то большое желание проделать подобное, то
тебя никакие меры не спасут

b0rmann писал(а):5.злоупотребить каналом

Это мне непонятно.
О чем идет речь? Нормальный хостер всегда располагает запасом трафика в несколько сотен гиг. Или это уже не хостер будет

Если PHP делается для хостинга - посмотри в сторону запуска PHP в виде CGI а не модуля Апач. Плюс suexec. Поможет решить ОЧЕНЬ много проблем.

Anonymous писал(а):Если PHP делается для хостинга - посмотри в сторону запуска PHP в виде CGI а не модуля Апач. Плюс suexec. Поможет решить ОЧЕНЬ много проблем.

Будут ли работать при этом php-сессии например?

Всегда внимательно читайте то, что написано мелким шрифтом в примечаниях ко всяческим изощрениям!