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

При написании движка возникла необходимость ограничения выполнения модулями функций 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 перед включением модуля и сравнивать со списком полученным после включения. Если добавилось лишнее -- бан. Это не спасает от первого вызова, не спасает от выхода из модуля без возврата в контроллер (хотя тут тоже можно попробовать поймать такие модули).

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

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

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

Как не крути сможет.

то есть?

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

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

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

Впрочем нет предела изврату, можно написать модуль ядра к SELinux, движок на чём угодно и контролировать любое IO... всего что есть на машине   

Sardar, я полностью с тобой согласен!!!

А как на счет управления на уровне файловой системы?
К примеру на FreeBSD. Реально ли дать доступ так, что бы только core.php мог открывать файлы модулей? 
Правда я ещё сам понять немогу как это должно выглядеть ... 

awers, нет.

  Улыбнуло. И вообще - автор темы идет не по тому направлению развития.

Аналогично 

Если автор так трепещет за несанкционированный доступ к модулям, можно еще извратиться, и спрятать модули где-нить на сервере в новой зеландии, а доступ разрешить только по вызовам удаленных процедур, например SOAP. Хотя еще раз повторюсь - это бред.

В принципе можно сварганить что-то вроде такого изврата:


  

а проблему запрета использования стандартного require можно решить проверкой файла модуля, убрав из него строки типа "require 'my_all.php';" с помощью регулярных выражений...

но это все, как говориться, методы "через задницу"   

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

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