I am trying to find solution for this problem for days.

I have structure like this.

               /other stuff

all requests goes to index.php which loads application in /app and plugins in /plugins.

in similar manner to wordpress application loads functions.php for each site.

I need to limit all code in function.php to access only directory structures above, and i have tried with dynamic ini set for open_basedir, just before functions.php loading, but problem is that application start running after functions.php, and loading everything from plugins and core via actions in hooks (again like in wordpress).

Problem is because whole app is OOP with composer dependencies, and plugins must be comptabile with composer, so composer just load autoloader for classes and then after functions.php when in some hook we have attached new SomeClassFromPlugin it actually tries to load class from directory from autoloader.

I need to have structure like this, because it is needed to plugins and core have "closed" code, and that users in similar manner to plugins can modify actions and hooks from functions php, but functions.php must be security safe from everything, and like sandbox.

Application must be compatible with hhvm and is running with user nginx (no multiuser)

Is there real solution or i must handle with obscurification of directory structure, but than again it is not enough, user can simply scandir('../..'..')

i am running centos -> nginx -> hhvm (fastcgi) -> php


Can you confirm that what you need is for public users to be able to hit index.php but not be able to directly call php files in any of the specified subdirectories?

If so the answer is here, with another option here.

For example

location ~* /plugins/.*.php$ {
    deny all;

location ~* /users/%site%/*.php$ {
    deny all;

Or simply

location ^~ /plugins/ {

You may be able to use regular expressions where you specified %site% so it applies to all sites.

  • You are not reading question well. I am not speaking about web requests. I am speaking about file access from php itself. Request is actually loading application php files and plugin php files, and in the end functions.php file. After that application goes app->run() which runs whole thing. User should be able to do everything he want in functions.php, to use application api to modify hooks and actions, but user shouldnt be able to load, read or erase ANY FILE below directory of functions.php, but still loaded plugins must be able to load files from own directory, and not below also. – Dejan Milosevic May 20 '16 at 20:02
  • I believe I've answered your question and that you may not understand the answer. However your question is unclear, which is why I requested clarification, which you've tried to provide but haven't done clearly. Please edit your original post to be more precise and clear about the problem and what you're trying to achieve. Do users of the system only call index.php and that php file calls the others, or do users of the system call functions and such directly? That is the key answer we need to help you. If it's the former, uses only call index.php, then my answer stands. – Tim May 20 '16 at 20:25
  • system only calls index.php, and accessing other script is already disabled via WEBREQUEST. I need to disable functions.php to include or require or file_get_content or scan_dir or have any access to directories BELOW, just like OPEN_BASEDIR would do in a simple configuration. – Dejan Milosevic May 20 '16 at 20:33

You need to know exactly what directories you want to include and put them in your php.ini's open_basedir which by the way allows multiple entries delimited by the PATH separator (: on Unix).

You can not say I want this directory included to do this or to do that. You either include it or not. If this poses a security concern, then you need to review your directory structures.

Needed source code needs to be accessible from the rest of the source, however you proceed.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.