Добрый вечер. 

При написании движка возникла необходимость ограничения выполнения модулями функций include, include_once, require, ...  Как это возможно осуществить? php4/5 

Благодарю, Аадм.

Написание программного кода.

Неужели сложно было в поиск вбить "модульность".

http://forum.vingrad.ru/topic-116824.html
http://forum.vingrad.ru/topic-49182.html
http://forum.vingrad.ru/topic-51073.html
http://forum.vingrad.ru/topic-15231.html

Что касается запрета. Необходимо знать КАК устроена ваша модульная структура.

Это сообщение отредактировал(а) Mal Hack - 6.1.2007, 14:40

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

теперь объясню для чего все это надо:
в обычных движках все сделано так, что "ядро" вызывает нужный ему модуль и отдает управление ему. т.е. по сути ядру пофиг что дальше делает модуль. 
я же, хочу ограничить обособленности модулей относительно ядра. ресурсами должно заведовать именно ядро, соответственно решать имеет ли право модуль с текущим уровнем доступа получить доступ к тому или иному ресурсу движка. то-же касается SQL запросов, но с ними проще (EXPLAIN QUERY), берем используемые модулем в запросе таблицы и решаем, можно ли ему туда писать/читать или вообще знать о них. а вот в случае с файлами - сложнее. что-бы для обхождения защиты модуль не мог сделать нечто типа 


Вот в чем вопрос. Надеюсь на этот раз правильно сформулировал.

Да, туда же всякие mkdir, dir() ... Надо ограничить хотя-бы частично, если возможно. 

Это сообщение отредактировал(а) awers - 6.1.2007, 15:58

Решение в создании перегрузке операций, т.к. делаем верхнюю надстройку в ядре. Т.е.
В ядре делаем метод my_mkdir() и в нем в зависимости от условий разрешаем или нет выполнение функции, при этом в модуле делаем вызов my_mkdir.

но дело в том что:
1) человек в модуле может просто написать include а не myinclude
2) при 

то что мы инклюдим не получает пространство переменных и наоборот.
к примеру взять так:
0001.php


0002.php


Мы получим ошибки что $d,$i не существуют. Т.Е. при инклюде из функции, "адресное пространство" ограничивается пределами функции.

Добавлено @ 17:23 
"Для чего мне все это?" - спросите Вы?
все очень просто. после установки Пользователем экземпляра моего движка, у пользователя может возникнуть необходимость установки модулей, в том числе и сторонних! я в свою очередь хочу гарантировать (хотя бы частично) Пользователю безопасность. Даже если сторонний модуль содержит вредоносный код - он не должен суметь его выполнить. 

awers, от этого  ничего не спасет, т.к. php не предоставляет перегрузки операторов и функций.

Т.е. единственный выход - модифицировать и рекомпилить сам php?

awers, это изврат, на самом деле...

Могу посоветовать, может я и не прав, но вроде логичнее сделать некую абстракцию, тоесть создать базовый для всех модулей класс, например CMSModule


Только необходимо определить загрузщик базовых классов твоей CMS
например 
файл configure.class.php


Это сообщение отредактировал(а) AntonioBanderaz - 8.1.2007, 02:41

Об этом я писал выше. Автор имел ввиду, тот случай, когда программист делая модуль сам может написать include()

Смысл короче в том чтобы определить в базовом классе модуля, необходимые переменные и ссылки на классы системы.
Это по поводу видимости переменных

По поводу проверки доступа для инклуда в модуле, это ты хоть аб стену расшибись не сделаешь если чел знает полный путь к файлу... Но если у тебя в CMS чисто объектный подход, то в 5-ке есть одна шняжка которая может помочь.
В php5 есть такая штука, как __autoload это функция вызывается при создании экземпляра класса, объявление которого отсутствует.
тоесть ты можешь только положиться на честность проггеров, которые будут писать модули, сделай типо предписание, что файлы надо назвать определённым образом, класть в определённые папки, и не использовать include в модулях... Описание функции __autoload http://www.php.net/__autoload

Есть ещё один вариант, если автору так хочется ограницить действия include (хотя это очень идеализированная архитектура). К примеру, при подключении модуля, ядро сохраняет его уровень доступа таким образом, чтобы никто кроме его самого (ядра) не мог его изменить, но все могли считать. Чтобы не возникало redeclair, наверное лучше использовать не константы а private-свойства объекта-ядра (это уже php5). А в каждом файле ресурсов перед выполнением стоял бы код, который проверяет текущий уровень доступа и соотвественно возможность исполнится.

awers, а не проще ли сделать глобальный PermissionManager::hasPermission("news.write.delete"), который проверяет привилегии текущего пользователя. В примере привилегия удалять новость (модуль "новости", тип "изменение", конкретное действие "удалить").

Ну а менеджер привилегий уже разбираеться с грантами типа news.write.* - доступно всё на запись, news.admin.* - доступны настройки модуля и т.д. ИМХО более здравая идея. Все привилегии должны обьявляться в системе, что бы из админовки ты мог видеть их/раздавать гранты.

Речь как раз и об этом.

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

Ну как полумера -- получать список http://php.net/get_included_files перед включением модуля и сравнивать со списком полученным после включения. Если добавилось лишнее -- бан. Это не спасает от первого вызова, не спасает от выхода из модуля без возврата в контроллер (хотя тут тоже можно попробовать поймать такие модули).

Равно, как и запрет инклюдов чтобы избежать подобного кода:

не спасет от аналога без инклюда типа: