php admin value open basedir

Для чего нужна и как использовать open_basedir

Директива open_basedir указывается в конфигурационном файле PHP (php.ini) и устанавливает директории, к которым может иметь доступ PHP. Под доступом понимаются любые действия с файлами: открытие (например, функции fopen() или gzopen()), записи и выполнения. Если директива open_basedir установлена и делается попытка запустить файл, который находится за пределами перечисленных директорий, то скрипт не запустится и выдаст ошибку:

Пример значения open_basedir:

В указанном примере разрешён запуск скриптов PHP, а также операции с файлами в директориях:

Директива open_basedir оказывает влияние на многие функции. Больше всего в ней смысла при использовании на уровне конфигурационных файлов веб-сервера на уровне директорий или виртуальных хостов.

По умолчанию, если значение open_basedir не установлено, разрешены файловые операции в любых директориях компьютера (на которые достаточно прав).

Специальное значение . (точка) обозначает, что рабочая директория скрипта будет использована в качестве базовой директории. Однако, это немного опасно, так как текущая директория скрипта может быть легко изменена с помощью chdir().

В httpd.conf, open_basedir может быть выключена (например, для некоторых виртуальных хостов) тем же способом, что и любая другая конфигурационная директива:

В Windows разделяйте директории символом ; (точкой с запятой). На всех остальных системах, разделяйте директории символом : (двоеточием). При работе в качестве модуля Apache, пути open_basedir автоматически наследуются от родительских директорий.

Источник

Тема: php_admin_value open_basedir

Опции темы

Поиск по теме

Собственно вопрос такой, из каких технических соображений директива устанавливается: php_admin_value open_basedir «/home/user/data:.» а не php_admin_value open_basedir «/home/user/data/www/domen.ru»? Возможно ли как то управлять этой директивой, в смысле что бы во время создания домена, использовался какой то макрос, а не данные по умолчанию.

а чем плохо то, что скрипты юзера смогут лазить по /home/user/data/? по-моему это вполне логично, что ющер может получить туда доступ

Как это чем плохо?! Например, тем что данная возможность может навредить в рамках целого аккаунта.

1. Взломав один сайт, используя PHP скрипт, можно получить список директорий и файлов других сайтов. Ну а с помощью include можно почитать нужные файлы, а дальше бери что полезно.
2. Имея доступ по FTP ограниченный папкой домена через PHP скрипт можно сделать то же самое, что и в 1 пункте, но без взлома сайта.

Комментарии к пунктам:
1. Те кто скажет что надо использовать безопасные скрипты, сразу же хочу вас разочаровать таких просто нет в природе, так как и коммерческое и бесплатное ПО имеет ошибки.
2. Понятное дело, что тот кто создает, кому то FTP доступ должен понимать чем это грозит, но исходя из того что, назначая пользователю даже на конкретную директорию домена, пользователь FTP может выйти за ее пределы, используя PHP скрипт. Что само по себе противоречит выставленным ранее ограничения на конкретную директорию домена. Иными словами дали эту директории домена значит таков уровень доверия и не больше.

Так разводите по разным аккаунтам разные сайты, а если хочется чтобы клиент из одного места и под одним логином управлял всеми своими сайтами, то тут уж что-то одно. Или тогда уж ручками в темплейт забить нужные данные.

Но вообще все эти рассуждения идут о том, а кто является главным и что он может делать?
Некоторые сочтут данную систему удобной, кто-то дырой в безопасности (ведь кто-то может дать пароль от панели вебмастеру, и запретить чтолибо делать, кроме самого сайта, но с другой стороны имея данный пароль ведь можно поменять всем пароли на почтовых ящиках и точно так же умыкнуть почту).

Смысл в том, что выход за рамки домена многим не приятен, чем именно написано выше. Дело в том, что данное поведение противоречит некоторым ограничениям, которые тут уже были изложены. Что касается темплейта то параметр php_admin_value open_basedir «/home/user/data/www/domen.ru» передается по умолчанию, а исправлять этот параметр вручную для каждого домена это не вариант. Разделять сайты на аккаунты, это же тоже не правильно да и опять же неудобно. Давать кому то пароль от всей панели это уже совсем другое дело, дабы тут и так становится ясно, что пользователь сможет управлять всем, что есть на аккаунте. Вот простой пример того что можно сделать имея доступ на одну из папок домена. Загружаем в папку простой PHP скрипт следующего содержания:

Что можно сделать, с этим всем говорить излишне…

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

Я с Вами согласен, но все, же хотелось бы иметь какой то выбор на уровне панели, иными словами кому надо то пусть делает на директорию пользователя, ну а кому такой вариант не нравится то на каждый домен. Наличие такого выбора никому не будет мешать, а даже наоборот будет гибкость в управление. Просто, на мой взгляд, панель это оболочка для облегчения управления сервером, но панель должна делать то, что нужно администратору, а не привязывать его к неким стандартам. Я понимаю, что всем не угодишь и поэтому считаю, что нужно предоставить право выбора оптимального варианта.

разделение безпасности внутри одного акаунта невозможна впринципе, т.к. все это работает и принадлежит одному системному пользователю.

Каким образом модно сделать если, например нет поддержки всего кроме PHP и то в режиме модуля. Оставьте все же выбор за нами сделайте тогда опцию для панели с помощью которой можно будет управлять open_basedir.

P.S. Обойти open_basedir реально но, только если в самом PHP будут ошибки, и это совсем другой разговор.

Все это похоже на попытки уйти от ответа. Всесто пространных рассуждений, как и что обходится — требуется всего-то написать, как сменить значение по-умолчанию. Господа разработчики забывают, что
а) на одном акке может быть несколько сайтов, которые не должны хотя бы на уровне РНР иметь доступ друг к другу
б) допустим мне надо отделить друг от друга поддомены —*мне получается надо для каждого поддомена отдельного юзера?

Я понимаю, что по-хорошему, надо конечно разделять юзерами, можно в jail сажать процессы, но это хорошо на полноценном сервере, на VDS Jail делать как-то перебор. А тут требуется хотя бы средствами РНР ограничить доступ.

Подписываюсь Если бы я хотел править конфиги — я бы не пользовался панелью. Тем более, что нет ничего ничего сложного в возможности править шаблон по-умолчанию.

Источник

Php admin value open basedir

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

Но некоторые движки сайтов (к примеру, 1С-Битрикс) для увеличения скорости работы настоятельно рекомендуют отключение данного параметра для сайта. Чтобы отключить его, следует отредактировать конфигурационный файл веб-сервера Apache. Этот файл или его часть с настройками сайта располагается в разных местах в зависимости от ОС, дистрибутива и используемой версии ISPmanager.

Найти раздел и для конкретного сайта и заменить параметр

Также конфигурационный файл можно исправить под root через интерфейс ISPmanager — Домены — WWW-домены — выделить нужный веб домен — кнопка «Конфиг»

Если нужно вообще отключить open_basedir и для всех последующих веб доменов, то в конфигурационный файл ISPmanager (/usr/local/mgr5/etc/ispmgr.conf) нужно прописать

После правки конфигурационного файла перезапустить core

Соответственно, в конфиг каждого нового VirtualHost будет добавлено

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

Некоторое время назад в целях повышения безопасности на наших серверах была включена настройка PHP open_basedir. После этого многие PHP-приложения перестали загружать файлы на сервер.

По ссылке много букв (которые всё-таки рекомендуется прочитать), здесь же напишу кратко:

Конечно же язык PHP разрабатывают неглупые люди, поэтому действие open_basedir не распространяется на функции is_uploaded_file и move_uploaded_file, которые, собственно, и предназначены для работы с загруженными файлами.

Так в чём же тогда проблема? А проблема вот в чём: многие (действительно многие!) обращаются к загруженным файлам именно напрямую, в обход стандартных функций.

Я настоятельно советую PHP-программистам (особенно начинающим), во-первых, не пренебрегать использованием стандартных функций. Если функцию написали, значит она для чего-то нужна. Во-вторых, хорошенько изучить настройки PHP и режимы его работы. Это поможет избежать таких вот ошибок.

P. S. Кто-то может сказать «нефиг так конфигурировать сервера, что скрипты перестают работать». Однако я считаю, что если настройка есть, то кто-нибудь её обязательно использует. И если ваша программа после этого перестанет работать, то камни полетят в вас. Оно вам (нам) надо?

Представленные здесь значения по умолчанию используются в случае, если не был подключен php.ini ; значения для боевого php.ini и для разработки могут различаться.

Языковые опции

Краткое разъяснение конфигурационных директив.

precision integer Количество значащих цифр, отображаемых для чисел с плавающей точкой. -1 означает, что будет использован усовершенствованный алгоритм для округления таких чисел. serialize_precision integer Количество сохраняемых значащих цифр при сериализации чисел с плавающей точкой. -1 означает, что будет использован усовершенствованный алгоритм для округления таких чисел. y2k_compliance boolean Включение совместимости с 2000 годом (создаст проблемы с несовместимыми браузерами) allow_call_time_pass_reference boolean

Нужно ли выводить предупреждение, если аргументы передаются по ссылке при вызове функции. Рекомендуется указывать в объявлении функции передаваемые по ссылке аргументы. Попробуйте выключить эту опцию и убедиться, что ваши скрипты правильно работают без нее и что они будут работать с будущими версиями языка (вы будете получать предупреждение каждый раз, когда вы будете пользоваться этой возможностью).

Передача аргументов по ссылке во время вызова функции была объявлена устаревшей из соображений чистоты кода. Функция может менять свои аргументы недокументированным способом, если бы аргумент не объявлялся передаваемым по ссылке. Чтобы избежать побочных эффектов, лучше явно указывать, какие аргументы передаются по ссылке только при объявлении функции.

Эта директива позволяет отключить некоторые функции по причинам безопасности. Она принимает список имен функций, разделенный запятыми. disable_functions не подвержена влиянию безопасного режима.

Только внутренние функции могут быть отключены с помощью этой директивы. Пользовательские функции ей не подвержены.

Если процесс стартован в режиме релиза, zend.assertions не может быть изменен во время выполнения, так как код утверждений не генерируется.

Если процесс стартован в режиме разработки, zend.assertions не может быть выставлен в -1 во время выполнения..

Включает режим совместимости с Zend Engine 1 (PHP 4). Это влияет на клонирование, приведение типов (объекты без свойств приводятся к FALSE или 0) и сравнение объектов. В этом режиме объекты по умолчанию передаются по значению вместо ссылки.

Эта возможность была помечена УСТАРЕВШЕЙ и БЫЛА УДАЛЕНА в версии PHP 5.3.0.

Разрешает парсинг исходных файлов в многобайтных кодировках. Включение zend.multibyte требуется для использования кодировок символов подобных SJIS, BIG5 и т.д., содержащих специальные символы в многобайтных строковых данных. Совместимые с ISO-8859-1 кодировки, например UTF-8, EUC и т.д., не требуют эту опцию.

Разрешение zend.multibyte требует установленного расширения «mbstring».

Данное значение будет использовано, только при отсутствии директивы declare(encoding=. ) в начале скрипта. При использовании кодировок несовместимых с ISO-8859-1, нужно использовать опции и zend.multibyte и zend.script_encoding.

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

Эта директива только для Apache1 mod_php, которая заставляет потомка Apache завершиться, если произошел тайм-аут исполнения скрипта PHP. Такой тайм-аут приводит к внутреннему вызову longjmp() в Apache1, который оставляет некоторые расширения в несогласованном состоянии. По завершении процесса все неснятые блокировки или память будут очищены.

Ограничения ресурсов

Краткое разъяснение конфигурационных директив.

Эта директива задает максимальный объем памяти в байтах, который разрешается использовать скрипту. Это помогает предотвратить ситуацию, при которой плохо написанный скрипт съедает всю доступную память сервера. Для того, чтобы убрать ограничения, установите значение этой директивы в -1.

Настройка производительности

Использование open_basedir отключит кеш realpath.

Краткое разъяснение конфигурационных директив.

Определяет размера кэша realpath, используемого в PHP. Это значение должно быть увеличено на системах, в которых PHP открывает большое количество файлов соответственно количеству выполняемых файловых операций.

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

Размер, необходимый для кэширования, зависит от системы.

Время (в секундах) в течение которого будет использован кэш realpath для указанного файла или директории. Для систем с редко меняющимися файлами это значение можно увеличить.

Обработка данных

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

Список разделителей, используемых PHP для получения переменных из URL.

Каждый символ в этой директиве считается разделителем!

Эта директива регулирует порядок, в котором PHP добавляет переменные GET, POST и Cookie в массив _REQUEST. Добавление производится слева направо, новые значения перезаписывают старые.

Когда включено, переменные SERVER, REQUEST и ENV создаются в тот момент, когда они впервые используются (Just In Time), а не в начале выполнения скрипта. Если эти переменные в скрипте не используются, включение этой директивы приведет к росту производительности.

Директивы PHP register_globals, register_long_arrays и register_argc_argv должны быть выключены для правильной работы этой директивы. Начиная с версии PHP 5.1.3 стало необязательно выключать register_argc_argv.

Использование переменных SERVER, REQUEST и ENV проверяется на стадии компиляции, поэтому их использование с помощью, например, переменных переменных не запустит их инициализацию.

Регистрировать или нет переменные EGPCS (Environment, GET, POST, Cookie, Server) в качестве глобальных переменных.

Начиная с версии » PHP 4.2.0, значением по умолчанию для этой директивы является off.

Пожалуйста, ознакомтесь с главой о безопасности Использование глобальных переменных для получения дополнительной информации.

На поведение register_globals влияет директива variables_order.

Данная возможность была объявлена УСТАРЕВШЕЙ, начиная с PHP 5.3.0 и была УДАЛЕНА в PHP 5.4.0.

Данная возможность была объявлена УСТАРЕВШЕЙ, начиная с PHP 5.3.0 и была УДАЛЕНА в PHP 5.4.0.

Источник

PHP open_basedir

How to enabled PHP open_basedir in CWP
** Note this is only for PHP-CGI

We have two options
— global config, one config file in the include folder /usr/local/php/php.d/ and in PHP selector include folders
— per-user config, the securest option as it restricts the user to his /home/USERNAME folder and also disables users from using custom php.ini files.

Global Configuration
The securest method do this correctly and to prevent users from overriding this is to place the config into the include file. Please note that if you set this into /usr/local/php/php.ini then custom user php.ini will be able to disable it. Please note that global config allows full /home folder access while per user restricts users to /home/USERNAME folder which is much more secure.

One line command to create a file and config:

You can also do it by yourself by creating a file: /usr/local/php/php.d/open_basedir.ini with the following content:

To enable it for other php versions from the PHP selector you can create this config files with the same content:

PHP info file example phpinfo.php

** Don’t forget to replace the USERNAME.

Please note that this option will also disable all further custom users php.ini files per folder, for example: /home/USERNAME/public_html/php.ini will not be loaded.

You can also place it into public_html folder but then users will be able to run custom php.ini files per folder and they can disable open_basedir.

RECOMMENDATION
We recommend using the per-user configuration of open_basedir as it will provide much higher security and isolate each client.

NGINX + PHP-FPM
configuration files are:
/etc/nginx/conf.d/vhosts/DOMAIN.conf
/etc/nginx/conf.d/vhosts/DOMAIN.ssl.conf

under fastcgi_param add one more line and reload/restart nginx

** Note that manual editing of the webserver vhost files is not recommended as those files get rebuilt from the template on each change.
Try checking the instructions here for the custom template build.

APACHE + PHP-FPM
Configuration files are all user existing php-fpm configuration files, to get the list of files you can use this

** Note that editing any of those files requires to restart php-fpm version you edited.

** Note that manual editing of the webserver vhost files is not recommended as those files get rebuilt from the template on each change.
Try checking the instructions here for the custom template build.

Источник

Тема: Указать php_admin_value open_basedir

Опции темы

Поиск по теме

По умолчанию ISP в директиве VirtualHost прописывает сайтам:
php_admin_value open_basedir «.:/var/www/LOGIN/data»

но нам нужно для ОДНОГО САЙТА подцепить модули PEAR, для этого меняем эту строку на:
php_admin_value open_basedir «.:/var/www/LOGIN/data:/usr/share/php:/usr/share/pear»

при этом все работает хорошо, но время от времени эта строчка опять меняется на дефолтную :
php_admin_value open_basedir «.:/var/www/LOGIN/data»
и модули конечно же перестают работать.

Просьба подсказать, как нам указать ISP не исправлять эту строчку?

Неужели никто не сталкивался с такой проблемой?

если в кратце, то можно решить шаблонизатором конф. файлов
Сделать спец тариф/шаблон в ISP например с названием PEAR
И уже от имени шаблона плясать дальше
https://doc.ispsystem.ru/index.php/Ш. �_файлов
Либо же просто запретить iSP переопределять ручные правки
https://doc.ispsystem.ru/index.php/Р. сервера
ИХМО: лично бы сделать через шаблонизатор, больше гибкости, и не теряется ничего

А можно пример набросать как добавить свою open_basedir? А то что-то никак не выходит.

Источник