Jump to:
| Project: | Drush |
| Version: | All-versions-5.x-dev |
| Component: | PM (dl, en, up ...) |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
file_exists(): open_basedir restriction in effect. [warning]
File(/etc/drush/drushrc.php) is not within the allowed path(s):
(/var/www/vhosts/:/tmp:/usr/local/bin:/usr/bin)
is_dir(): open_basedir restriction in effect. [warning]
File(/usr/share/drush/commands) is not within the allowed path(s):
(/var/www/vhosts/:/tmp:/usr/local/bin:/usr/bin)
file_exists(): open_basedir restriction in effect. [warning]
File(/var/www/settings.php) is not within the allowed path(s):
(/var/www/vhosts/:/tmp:/usr/local/bin:/usr/bin)
file_exists(): open_basedir restriction in effect. [warning]
File(/var/settings.php) is not within the allowed path(s):
(/var/www/vhosts/:/tmp:/usr/local/bin:/usr/bin)
How do I get around this?
Why is it calling for /var/www/settings.php or /var/settings.php
Thanks,
Chris
Comments
#1
Try to set open_basedir variable to NO VALUE.
#2
Well unsetting open_basedir is not what we want to do!
I do not know if it is a bug or a feature, but how can I make drush stop looking for the (not existing) /etc/drush/drushrc.php file?
I do not want to let php read my config dir (/etc).
#3
Drush searches for configuration files using the logic in
function _drush_config_file($context)in includes/context.inc. Drush could call ini_get on open_basedir, and skip configuration paths that are not allowed to php.Drush will also search for settings.php files by starting at the cwd and walking up towards the root of the filesystem until it finds something. This walk up should also respect open_basedir, and stop iterating if it would walk out of the range of directories php can read from.
#4
Can you change those file_exists() calls to is_readable and see if the warnings disappear?
#5
That would have been quite an elegant solution; unfortunately, is_readable also throws the same "open_basedir restriction in effect" warning.
The Debian php.ini file calls open_basedir a "broken" security measure. Files can be protected from the webserver via filesystem permissions; also it is possible to set an open_basedir for the webserver, but leaves it open in the php-cli php.ini file. Fixing this would perhaps involve creating a "drush_is_readable" or "drush_file_exists" function that did the appropriate filesystem path check, and all of the locations that are impacted would have to call it. Maybe there are only a few places, but it seems like a bit of a hassle.
Maybe someone who thinks this is important enough to warrant the work can submit a patch.
#6
I think the Debian maintainer is perhaps misunderstanding the use case for open_basedir. Suppose I have a virtual hosting setup where I set my document roots to a path like this:
/srv/www/[site-name]/htdocs/The web server can prevent serving files from outside the document root, but it won't stop a CGI script from reading them unless I run PHP under suPHP or suEXEC and change file ownerships accordingly, both of which mean I can't run PHP under mod_php.
All the paths must be at least readable by the web server, so normally a script running on one site can automatically see all files owned by all other sites. To prevent that, I can set
php_admin_value open_basedir '/srv/www/[site-name]/'in the virtualhost configs, thereby preventing ClientA's PHP scripts from being able to open ClientB's files.I'm not endorsing open_basedir, just showing a case where it might be useful. However, I do think drush should be able to work without throwing warnings when it tries to find files that probably aren't there anyway.
#7
Is there a fix for this? this is really annoying. I have no idea why drush needs to be looking outside its domain. If anyone has a solution but wants me to code it, i'd be _very_ happy to do so. Write these kinds of things to a log file maybe? write them to a drupal log?
anyone?
Not sure how this is relevant, as comment #6 went over my head, but incase it is:
I'm working on an archlinux install and have my sub domain tree like:
sites.com: /srv/http/www/
and subFun.site.com: /srv/http/subfun/www
#8
This would be a lot of work, and I don't really see a value to it. Perhaps you might want to set up open_basedir for the web server as mentioned in #6, but drush uses the cli php.ini, so you can just turn open_basedir off for the cli.
#9
agree with greg's summary
#10
a simple workaround on Archlinux:
create the following directories using root: /etc/drush and /usr/share/drush. No files in them. 755 as permissions, root is owner.
Then append the following to your open_basedir configuration in php.ini:
:/etc/drush/:/usr/share/drush/
Mine looks like this:
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/etc/drush/:/usr/share/drush/
The above should fix the error message without adding any security concerns.
Hope this helps,
Fabio Varesano
#11
this may be a stupid question, but... does this error indicate an actual issue, or is it just an annoyance?
also, in #8 greg.1.anderson says, "drush uses the cli php.ini, so you can just turn open_basedir off for the cli."
would anyone be willing to detail how to do so?
#12
I'd like to know more about this as well. I'm running Drush on MediaTemple's grid server, so I don't have root access. These warning messages are a big nuisance.
#13
If you use a recent version of drush-HEAD, you can copy your webserver's php.ini to your $HOME/.drush directory and edit it as you see fit. Edit the open_basedir line so that it reads
open_basedir =to turn off open_basedir for drush.For additional comments, see #918468: drush.ini or php.ini? [Drush should use php.ini files in drush conf folders + some fixes for drush paths that contain spaces], which will further simplify things by adding a drush.ini file that only needs to contain definitions for the items you want to change; all other values are inherited from the main php.ini file.
#14
Automatically closed -- issue fixed for 2 weeks with no activity.