свой tmp в php для каждого пользователя

Евгений Крупченко
На сайте с 27.09.2003
Offline
161
573

когда php из apache работает, то в конфигах виртуальных хостов прописывается.

типа такого:

php_admin_value upload_tmp_dir /var/www/vhost1/tmp

php_admin_value session.save_path /var/www/vhost1/session

а как тоже самое сделать когда php cli запускается, например cron заданием?

в этом случае конфиги апача не участвуют и путь берется из общего php.ini

т.е. сессии и все временное скидывается в общую папку (/var/lib/php5)

можно что-то придумать? может как-то сделать чтоб php.ini свой подгружался для каждого пользователя?

или ткните где почитать или где спросить.

:confused:

N
На сайте с 06.05.2007
Offline
419
#1

EvGenius, речь идет о предоставлении услуг хостинга или вы для своих личных сайтов хотите этого?

Можно же просто запускать не просто /usr/bin/php, а соответствующими ключами и конфигурационным файлом.

Кнопка вызова админа ()
Евгений Крупченко
На сайте с 27.09.2003
Offline
161
#2

речь о предоставлении другим. т.е. задача какраз их разделить и ограничить.

мысль примерно понял...

т.е. в кроне просто дописывать при запуске использовать особый php.ini

в принципе как вариант. но это решает только проблему cron'ом.

но хотелось бы более глобально. чтоб на ту общую папку вообще закрыть всем доступ допустим и нигде потом из-за этого не всплыли ошибки какие-нибудь.

2) еще заодно вопрос. стоит ли заморачиваться с open_basedir?

производительность малость снижает, а обойти запросто можно если например не php, а perl скриптом воспользоваться.

может правильней просто следить чтоб у аттрибуты "для всех" не стояли там где не надо?

тогда пусть шарятся по всему серверу, но куда не надо просто не будет доступа - в первую очередь это файлы соседей, какие-нибудь конфиги где прописаны пароли...

pupseg
На сайте с 14.05.2010
Offline
329
#3

"может правильней просто следить чтоб у аттрибуты "для всех" не стояли там где не надо?" - вообще, классически, и это концепция Unix-like - именно так и делать.

и у ряда хостингов ,в том числе и гигантов - так и сделано.

Грамотно настроенные права доступа, отсутствие чтения кем попало конфигов и приватных файлов, tmp в noexec,nosuid , отсутствие компиляторов на сервере хостинга и т д - этого достаточно для безопасности.

Качественная помощь в обслуживании серверов. (/ru/forum/661100) Бесплатных консультаций не даю, не помогаю, не обучаю. Минималка от 100$. Как пропатчить KDE-просьба не спрашивать. Есть форумы (http://linux.org.ru) и полезные сайты (http://www.opennet.ru/).
N
На сайте с 06.05.2007
Offline
419
#4
EvGenius:
речь о предоставлении другим. т.е. задача какраз их разделить и ограничить.

ну тогда напрягитесь и сделайте вместо /usr/bin/php свой скрипт-враппер, который определяет кто его вызвал, подставляет нужный php.ini, запускает уже сам php.

Евгений Крупченко
На сайте с 27.09.2003
Offline
161
#5

еще одна хорошая мысль :]

N
На сайте с 06.05.2007
Offline
419
#6

даже при таких потребностях создавать php.ini не нужно, можно обойтись php -d session.save_path = .

Но пользователи могут и захотеть иметь свой php.ini

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий