URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 69301
[ Назад ]

Исходное сообщение
"PHP mod_php. Виртуальные хосты и права на файлы."

Отправлено sargio , 03-Окт-06 22:58 
Апач user nodbody,  php mod_php.

Как выставить права (как приведено ниже) , но чтобы php (apache) могу читать их и испольнять файлы из деректорий?
(никак не соображу как, видел такое, но повторить никак не удается)

ls -al /home/user1/

drwx------    5 user1     user1   512 Mar 27  2006 .
drwx------   29 user1     user1   1536  Oct  1 22:27 www

ls -1  /home/user1/www

-r--------   1 user1     user1     100112 Oct  1 20:47 index.php



Содержание

Сообщения в этом обсуждении
"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено seller , 04-Окт-06 19:13 
>Апач user nodbody,  php mod_php.
>
>Как выставить права (как приведено ниже) , но чтобы php (apache) могу
>читать их и испольнять файлы из деректорий?
>(никак не соображу как, видел такое, но повторить никак не удается)
>
>ls -al /home/user1/
>
>drwx------    5 user1     user1  
> 512 Mar 27  2006 .
>drwx------   29 user1     user1   1536  Oct  1 22:27 www
>
>ls -1  /home/user1/www
>
>-r--------   1 user1     user1  
>  100112 Oct  1 20:47 index.php

Зачем исполнять? Вы что, пользуетесь php как интерпретатором через CGI? Или пускаете из командной строки?

chown -R nobody /home/user1/www/
ну уж если хочется, чтобы nobody мог читать _и_ выполнять, сделайте
chmod 500 /home/user1/www/index.php

вариант 2, чтобы и user1 мог читать/выполнять.
chown -R user1:nobody /home/user1/www/
chmod -R 750 /home/user1/www/
chmod 750 /home/user1/www/index.php

тогда у вас будет:
drwxr-x---   29 user1 nobody 1536  Oct  1 22:27 www
-rwxr-x---   1 user1 nobody 100112 Oct  1 20:47 index.php

Если это все не устраивает, копайте в сторону ACL (access control lists).


"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено sargio , 04-Окт-06 19:46 
>Зачем исполнять? Вы что, пользуетесь php как интерпретатором через CGI? Или пускаете
>из командной строки?
да, конечно же, читать.  описался.

Кратко зачем нужны требуемые права:

для решния роблемы с чтением файлов других пользователей при помощи php или CGI.

То есть если выставить права, которые вы привели ниже, то получится что user2 сможет прочитать файлы из директории  user1 (/home/user1/www).

Для CGI проблему можно решить через suexec, но как поступить если стоит
mod_php (переходит на php-cgi не хочется, потеряется http авторизация.)?

У хостеров как то данная проблема решена, причем там стоит apache без suexec, без suphp и рhp как модуль apache. И выходит что скрипты запускаются от пользователся, так как   при правах (7)00 на index.php для user1  скрипт исполняется.



"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено seller , 05-Окт-06 09:54 
>То есть если выставить права, которые вы привели ниже, то получится что
>user2 сможет прочитать файлы из директории  user1 (/home/user1/www).

Если он принадлежит группе nobody, то сможет.

>У хостеров как то данная проблема решена, причем там стоит apache без
>suexec, без suphp и рhp как модуль apache. И выходит что
>скрипты запускаются от пользователся, так как   при правах (7)00
>на index.php для user1  скрипт исполняется.

Можно использовать директивы
User user1
Group user1

в секции <virtualHost *>, если у вас виртуальные хосты настроены,
<VirtualHost *>
ServerName user1.site.ru
ServerAlias www.user1.site.ru
User user1
Group user1
DocumentRoot ...
<Directory ...>
...
</Directory>
</VirtualHost>
Тогда файлам можно давать права 700.

А если вы пользуетесь mod_userdir и хостите пользователей из их домашних директорий на дареса типа site.ru/~username, то в таком случае я, к сожалению, по памяти не скажу, где-то у меня было решение такой проблемы, надо поискать... Но и там ничего хитрого не было...


"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено PavelR , 05-Окт-06 11:25 
>Кратко зачем нужны требуемые права:
>для решния роблемы с чтением файлов других пользователей при помощи php или
>CGI.

>То есть если выставить права, которые вы привели ниже, то получится что
>user2 сможет прочитать файлы из директории  user1 (/home/user1/www).
>
>Для CGI проблему можно решить через suexec, но как поступить если стоит
>mod_php (переходит на php-cgi не хочется, потеряется http авторизация.)?

Mod_suphp содержит в себе стык поддержки http-авторизации.

>У хостеров как то данная проблема решена, причем там стоит apache без
>suexec, без suphp и рhp как модуль apache. И выходит что
>скрипты запускаются от пользователся, так как   при правах (7)00
>на index.php для user1  скрипт исполняется.

Если стоит mod_php то хостеры включают safe_mode и пользователь просто  не может заставить php читать файлы за пределами разрешенных каталогов.


"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено sargio , 05-Окт-06 11:58 
2seller
На сколько я знаю, user user1 Group user1 в виртуал хост это для suexec, тогда php должен быть как cgi.
Если так, то  не годится, так как он должен быть как модуль apache.


2PavelR
Нет. У хостеров mod_php, но без safe_mode. Safe_mode, не панацея с постоянными репортами о его обходах, да и много чего не работает.


У хостеров именно mod_php, но с правами для каждого пользователя (Apache 1.x у большинства стоит).  Вроде такое можно сделать в Apache 2.x, в ветке 1.x, на сколько я  знаю, можно добиться только правив исходники апача.

BTW Как себя ведет mod_suphp на Apach 1.3.x c PHP5, работает эта связка, вы случаем не в курсе?



"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено seller , 05-Окт-06 13:17 
>У хостеров именно mod_php, но с правами для каждого пользователя (Apache 1.x
>у большинства стоит).  Вроде такое можно сделать в Apache 2.x,
>в ветке 1.x, на сколько я  знаю, можно добиться только
>правив исходники апача.

Может все-таки ACL?
Дать права на скрипт
для user1 - rwx,
для nobody  - r--,
для групп - ---,
для остальных - ---.


"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено sargio , 05-Окт-06 13:32 
>>У хостеров именно mod_php, но с правами для каждого пользователя (Apache 1.x
>>у большинства стоит).  Вроде такое можно сделать в Apache 2.x,
>>в ветке 1.x, на сколько я  знаю, можно добиться только
>>правив исходники апача.
>
>Может все-таки ACL?
>Дать права на скрипт
>для user1 - rwx,
>для nobody  - r--,
>для групп - ---,
>для остальных - ---.

Может я что то не так понял? Для nobody  - r-- --> user2 уже может прочитать скрипт user1 .

Да у хостеров можно просто ставить права только дял user1 для остальных 00, те. ?00. Так что видмо как  то по другому.


"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено seller , 05-Окт-06 13:41 
>>Может все-таки ACL?
>>Дать права на скрипт
>>для user1 - rwx,
>>для nobody  - r--,
>>для групп - ---,
>>для остальных - ---.
>
>Может я что то не так понял? Для nobody  - r-- --> user2 уже может прочитать скрипт user1 .
Не может, он пользователь user2, а не nobody :)

В acl можно перечислить несколько пользователей.
Собсно, я указал права соответственно для:
пользователя user1
пользователя nobody,
всех групп
остальных.

В обычных правах (chmod),
когда например у файла rwxr---- user1:nobody, из консоли пользователь user2 прочитать файл не сможет, если только он не относится к группе nobody. А апач, выполняя скрипты из папки user2, в любом случае сможет прочитать файл, т.к. скорее всего он запущен с правами nobody:nobody.


"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено sargio , 05-Окт-06 14:05 
>>>Может все-таки ACL?
>>>Дать права на скрипт
>>>для user1 - rwx,
>>>для nobody  - r--,
>>>для групп - ---,
>>>для остальных - ---.
>>
>>Может я что то не так понял? Для nobody  - r-- --> user2 уже может прочитать скрипт user1 .
>Не может, он пользователь user2, а не nobody :)
>
>В acl можно перечислить несколько пользователей.
>Собсно, я указал права соответственно для:
>пользователя user1
>пользователя nobody,
>всех групп
>остальных.
>
>В обычных правах (chmod),
>когда например у файла rwxr---- user1:nobody, из консоли пользователь user2 прочитать файл
>не сможет, если только он не относится к группе nobody. А
>апач, выполняя скрипты из папки user2, в любом случае сможет прочитать
>файл, т.к. скорее всего он запущен с правами nobody:nobody.

User 2 понятно что не сможет. Скрипт php user2 сможет. Проблема в том что скрипты запускаются от nobody, что у User1, что у User2. Следовательно скрипт User2(так как он от nobody) сожет прочитать срипты User1 (так как на них должны стоят права read для nobody, иначе apache не сможет их прочитать и интерприторовать)
файл User1.



"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено яша , 05-Окт-06 14:48 
>User 2 понятно что не сможет. Скрипт php user2 сможет. Проблема в
>том что скрипты запускаются от nobody, что у User1, что у
>User2. Следовательно скрипт User2(так как он от nobody) сожет прочитать срипты
>User1 (так как на них должны стоят права read для nobody,
>иначе apache не сможет их прочитать и интерприторовать)
>файл User1.
Ну да, апач в любом случае прочитает. А к чему это я написал? А фиг его знает, соображаю уже туго, ночь не спал...

Есть еще такой вариант:

<VirtualHost www.example.com>
  ServerName www.example.com
  DocumentRoot /www-home/example.com
...
  <Location />
   php_admin_value open_basedir    \ "/www-home/example.com/:/usr/lib/php/"
  </Location>
</VirtualHost>

Взято с раздела Безопасность мануалки с php.net.


"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено sargio , 05-Окт-06 14:58 
>>User 2 понятно что не сможет. Скрипт php user2 сможет. Проблема в
>>том что скрипты запускаются от nobody, что у User1, что у
>>User2. Следовательно скрипт User2(так как он от nobody) сожет прочитать срипты
>>User1 (так как на них должны стоят права read для nobody,
>>иначе apache не сможет их прочитать и интерприторовать)
>>файл User1.
>Ну да, апач в любом случае прочитает. А к чему это я
>написал? А фиг его знает, соображаю уже туго, ночь не спал...
>
>
>Есть еще такой вариант:
>
><VirtualHost www.example.com>
>  ServerName www.example.com
>  DocumentRoot /www-home/example.com
>...
>  <Location />
>   php_admin_value open_basedir    \ "/www-home/example.com/:/usr/lib/php/"
>  </Location>
></VirtualHost>
>
>Взято с раздела Безопасность мануалки с php.net.

Да есть, такое. Да, но это не совсем то что нужно, так как данное решение ограничивает ряд функций php (ну скажем, fopen файла с другого хоста уже не получится).

У хостеров именно запусакеются  php  от имени пользователя. Если удастся так запустить , то можно решить проблему с доступом и cgi скриптов, без использования suexec. У хостеров apache без suexec, su_php итд ничего этого нету. И скрипты запускаются от пользователя.
Вот только как?



"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено seller , 05-Окт-06 15:07 
>Да есть, такое. Да, но это не совсем то что нужно, так
>как данное решение ограничивает ряд функций php (ну скажем, fopen файла
>с другого хоста уже не получится).
>
>У хостеров именно запусакеются  php  от имени пользователя. Если удастся
>так запустить , то можно решить проблему с доступом и cgi
>скриптов, без использования suexec. У хостеров apache без suexec, su_php итд
>ничего этого нету. И скрипты запускаются от пользователя.
>Вот только как?

Прошлый пост (яша) это я. Пора сгонять всех со своего рабочего компа нафик...

Эхх, больше ничего такого на ум не приходит...
Единственное, что еще крутится в голове, так это chroot, но я не в курсе как он применим (и применим ли вообще) к mod_php, не копал так глубоко, т.к. не было необходимости.
Сдается мне, что так, как хостеры делают - решение не из простых/штатных, а какое-то хитрое, иначе упомянули бы о нем хотя бы в той же мануалке с пхп.нет (а может и я просмотрел).
А suexec принципиально нельзя использовать? Может у самих хостеров спросить, как они это делают?


"PHP mod_php. Виртуальные хосты и права на файлы."
Отправлено sargio , 05-Окт-06 15:25 
>>Да есть, такое. Да, но это не совсем то что нужно, так
>>как данное решение ограничивает ряд функций php (ну скажем, fopen файла
>>с другого хоста уже не получится).
>>
>>У хостеров именно запусакеются  php  от имени пользователя. Если удастся
>>так запустить , то можно решить проблему с доступом и cgi
>>скриптов, без использования suexec. У хостеров apache без suexec, su_php итд
>>ничего этого нету. И скрипты запускаются от пользователя.
>>Вот только как?
>
>Прошлый пост (яша) это я. Пора сгонять всех со своего рабочего компа
>нафик...
>
>Эхх, больше ничего такого на ум не приходит...
>Единственное, что еще крутится в голове, так это chroot, но я не
>в курсе как он применим (и применим ли вообще) к mod_php,
>не копал так глубоко, т.к. не было необходимости.
>Сдается мне, что так, как хостеры делают - решение не из простых/штатных,
>а какое-то хитрое, иначе упомянули бы о нем хотя бы в
>той же мануалке с пхп.нет (а может и я просмотрел).
>А suexec принципиально нельзя использовать? Может у самих хостеров спросить, как они
>это делают?

Хочется именно mod_php. Хостеры не скажут. Есть у меня один вариант с правкой исходника apache. Но это как последний вариант. Но не хочется потом  при апдейте геморой получить.

Я бы suexec ипользовал, но php будет cgi. Пропадет часть функцинальности. Вроде как через su_php, можно заставить работать http авторизацию,но нет гаранти что не потяряется еще часть функциональности. Да и не su_php не нравиться мне, уж лучше suexec и cgi или уж safe mode и open_base_dir.

Но вот решение ведь есть с mod_php, хочется понять какое.