How to get around the open_basedir restriction?

[TerryH]

I have a dedicated server, and for some reason PHP is returning open_basedir restriction warnings all over the place. As a result it can't find a lot of the auxiliary files that I ought to have, and I think my MediaWiki installation will be permanently compromised as a result.

I'd like to use my own php.ini file, but I can't seem to get the php engine to read it.

What am I missing?

[jason]

Is there a reason why you are using open_basedir right now, or is it just something that was enabled by default?

Your server's main php.ini file is probably located in /etc. Hve you tried turning open_basedir off in that (note that if you are running PHP as an Apache module (mod_php) you will need to restart Apache before the change will be noticed). You can also change the setting for individual VirtualHosts in httpd.conf by setting

[code]php_admin_value open_basedir none[/php]

You can also use the above to set host-specific open_basedir paths. If you are running mod_php I don't believe you can use individual php.ini files.

If you aren't using mod_php I'll need to know a bit more about your setup to help you debug.

--Jason

[impleri]

Plesk came with it enabled by default on my server. I haven't been able to figure out how to actually disable, but I have edited the particular httpd.include for each domain/subdomain that I've needed to do so (mainly programs that use absolute path references and, of course, ones that make calls to scripts in other [sub]domains).

[TerryH]

Thanks to everyone who replied.

I imagine that some members of the JaguarPC tech team are going to have heart attacks when they learn that we are shamelesly "hacking" the httpd.include file--the one having the commented text that says DO NOT EDIT UNDER PENALTY OF LAW! Just kidding.

Anyway, I changed the open_basedir to "/", and that solved the problem.

What I'd really rather do, however, is list more than one open_basedir, in order to use only the paths that I absolutely need to have open.

[Gwaihir]

The problem with editing things you're not supposed to is usually that the next software update will overwrite your changes with the defaults again. On top of that, it may confuse support, as they'd likely work under the assumption that such files are indeed not touched.

Note that you don't need open_basedir at all here at JagPC. The security issue open_basedir tries to plug (in combination with some other precautions that you'd have to take as well), is taken care of much better by running PHP in CGI mode. JagPC is well aware of how to do that, as all shared servers run that way. Once PHP runs in CGI mode you can use the standard system of file and folder permissions to regulate what accounts / users have access to what.

[jason]

What I'd really rather do, however, is list more than one open_basedir, in order to use only the paths that I absolutely need to have open.

You can do that. Just separate the paths with a colon (or semicolon on Windows).

php_admin_value open_basedir /home/user:/somewhere/else:/another/path

--Jason

[Vin DSL]

I have a dedicated server, and for some reason PHP is returning open_basedir restriction warnings all over the place.

What am I missing?

Sounds like a bad path in a 'config' file (or something) to me.

Why? Anecdotal evidence...

http://www.lenon.com/postp226.html

[impleri]

What I really want to do is find the source template for generating httpd.include and modify it to set the open_basedir path to the account's home directory. Setting it to root means that they can include anything they have the proper permissions for (something I don't want to do).
My current workaround is creating /var/www/vhosts/DOMAIN/conf/vhost.conf and putting this into the file:

<Directory /var/www/vhosts/DOMAIN/httpdocs>
        <IfModule sapi_apache2.c>
                php_admin_value open_basedir "/var/www/vhosts/DOMAIN/"
        </IfModule>
        <IfModule mod_php5.c>
                php_admin_value open_basedir "/var/www/vhosts/DOMAIN/"
        </IfModule>
</Directory>

It also works for subdomains (As long as it is modified accordingly).