Skip to content

Stupid open_basedir handling in PHP

Posted by Andreas 'ads' Scherbaum on

I have an application which has to run on different webservers (or to be more specific on servers with a different directory layout). On one server the php files are in /usr/home, the next one is using /www, the third one /var/www and last but not least my laptop has the files in my home directory which is below /home.

No problem - or?

Since we want a bit security, we have open_basedir activated. Now the script has to check if a specific directory exists. I added this directory name to the open_basedir settings on all webservers. But surprise PHP tries to be intelligent. On servers where the specific directory does not exist, PHP removes the directory name from the open_basedir directory list (note: this cost another stat() call on startup).

You imagine what comes next? Now the is_dir() call on this server fails, because of an "open_basedir restriction in effect" error.

*grrr*
  • Twitter
  • Bookmark Stupid open_basedir handling in PHP at del.icio.us
  • Facebook
  • Google Bookmarks
  • FriendFeed
  • Digg Stupid open_basedir handling in PHP
  • Bloglines Stupid open_basedir handling in PHP
  • Technorati Stupid open_basedir handling in PHP
  • Fark this: Stupid open_basedir handling in PHP
  • Bookmark Stupid open_basedir handling in PHP at YahooMyWeb
  • Bookmark Stupid open_basedir handling in PHP at Furl.net
  • Bookmark Stupid open_basedir handling in PHP at reddit.com
  • Bookmark Stupid open_basedir handling in PHP at blinklist.com
  • Bookmark Stupid open_basedir handling in PHP at Spurl.net
  • Bookmark Stupid open_basedir handling in PHP at Simpy.com
  • Bookmark Stupid open_basedir handling in PHP at blogmarks
  • Bookmark Stupid open_basedir handling in PHP with wists
  • wong it!
  • Bookmark using any bookmark manager!
  • Stumble It!
  • Identi.ca

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Stephan Jaensch on :

There are several possible solutions to your problem: 1. Use relative paths and set up the systems accordingly. 2.Use a local configuration file that stores the path to the directory. Both options are a better application design than the current solution (I presume you hardcoded all possible paths in your code and then check which one is the right one). Both solutions make sure that the application continues to work even when you install it on another 10 servers with different filesystem layouts. Solution number 2 makes sure you have to edit just one configuration file instead of having to modify the source code.
Comments ()

Andreas Scherbaum on :

Your "solution" is just a (not working) workaround. Sometimes you can't change the directory layout because you don't manage the server. In my case i have to hardcode the pathnames, because they are not inside my document_root (so relative pathnames would not work anyway) and if the directory exist, i have to change some environment variables based on the directory name. As a side note: if the directory would be inside document_root there is no need for adding the directory to open_basedir. Yes, the directory name is hardcoded: if you have a configfile and some ppl are allowed to change the application, you end up with a situation where someone overwrites this configfile with other values. No good plan for the real world.
Comments ()

Stephan Jaensch on :

That's not true. :) Two possibilites: Either "some ppl" are allowed to change the source inside the document root. Then they can already do everything they want with the source. Or they are not allowed to modify the source. Then you just upload the correct configuration file for each webserver and you are set. No need to modify the source code or to check 5 (later 10, 20, ...) different paths to find the right one. If you are afraid people will break stuff by having write access, remove it. If people set incorrect configuration values, they deserve to get an error. And using a config file was just one example - the point was to make it configurable instead of hardcoding it in the application. You may want to store these deployment-dependent settings in a database. Where you store them is not the issue - just don't hardcode deployment-dependent data inside an application.
Comments ()

Andreas Scherbaum on :

seufz The directory does only exist on one of the servers and in this case the path must go into a specific environment variable to make sure, an external program is catching up the right settings. So no need for source code changes with more servers. About the write access: it's a (big) difference if ppl change some specific files they know about or if ppl modify the entire application. But then i should take care that changes in one version of this file work on all servers - your attempt will not do so. By the way, i want to rant about PHP here ;-)
Comments ()

Stephan Jaensch on :

Yes I know, you like to do that. Still, I do not think this is a PHP problem. It might even be documented that nonexistant paths are removed from the open_basedir setting (I don't know, but it does sound sensible, maybe it is even good for security purposes). The fundamentally wrong thing here is that you have a deployment (server) dependent setting in source code. It doesn't matter if you need it in the environment or how you use it, it should not be hardcoded in PHP source code. And I agree with you, telling people to modify one specific, well documented configuration file is completely different than modifying source code. That's why I would opt for that solution. It can even be a PHP file. I see no reason why that wouldn't work or why that solution would be inferior to just hardcoding the paths. Care to enlighten me?
Comments ()

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.
Form options