Handle open_basedir

[Seldaek]

@LazyTown (anyway that was the IRC name, if it's not the same person on github apologies for the spam) reported this issue:

[  file_exists(): open_basedir restriction in effect. File(/root/.composer/.htaccess) is not within the allowed path(s):
(/var/www/vhosts/myhost.com/symfony_projects:/var/www/vhosts/myhost.com/backoffice:/var/www/vhosts/myhost.com/staging:/usr/bin/php:/tmp)

Either we catch it and advertise the use of COMPOSER_HOME, or we just skip writing silently or with a soft warning.

[till]

In this case – so how do they end up with this error?

I'm guessing php.ini has mostly web-settings and they ran this from the CLI?

[Seldaek]

Well composer just writes in $HOME, so even ran from the web, I'm pretty sure it'd have failed. It's already failing gracefully if you don't have permissions, the problem is that file_exists() fails with an error when open_basedir is active.

[wilmoore]

NOTE: As of PHP 5.3.0 open_basedir can be tightened at run-time (which also implies that it could be loosened).

[Seldaek]

I don't think it implies that :) You can improve security by tightening, but not mess with the base config I believe. I tried it and indeed it only works in the tightening direction.

[wilmoore]

I guess I was too optimistic and didn't have time (too lazy) to try it -- my bad :)

[ux-engineer]

+1

[HLFH]

+1

[krtek4]

If you are stuck with the same issue, note that you have to add /root/ to your open_basedir config otherwise PHP won't be able to create the /root/.composer directory. Was stuck for 1 hour trying to understand why :

file_exists(): open_basedir restriction in effect. File(/root/.composer/.htaccess) is not within the allowed path(s): (/vagrant/:/etc/pki/tls/certs/:/root/.composer/)

[baptistedonaux]

+1

[richard-ejem]

Adding /root and /usr/bin to open_basedir is a crazy security risk.

You may use safer solution:

<?php
putenv('COMPOSER_HOME=/var/www/composer-home'));
putenv('COMPOSER_CACHE_DIR=/var/www/composer-cache'));

[HLFH]

@Seldaek Any news?

[Seldaek]

Nope, nobody cared enough to fix it so far it seems.

[cclose]

If this helps anyone... I use the following shell-script as a wrapper around my composer.phar to deal with this:

#!/bin/bash

#install composer if it's missing
if [ ! -f 'composer.phar' ] ; then
  echo "Composer Not Found... installing"
  curl -sS https://getcomposer.org/composer.phar > composer.phar
  if [ $? -eq 0 ] ; then 
    echo "Installed!"
  else
    echo "Composer failed to install!";
    exit 1;
  fi
fi

#double check
if [ ! -f 'composer.phar' ] ; then
  echo "Composer failed to install!";
  exit 1;
else
  COMPOSER_HOME='/var/www/composer/home' COMPOSER_CACHE_DIR='/var/www/composer/cache' bash -c "php -d allow_url_fopen=1 -d suhosin.executor.include.whitelist=phar composer.phar $@";
fi

In addition to redirecting the COMPOSER_HOME and COMPOSER_CACHE_DIR to open_basedir acceptable dirs, this makes distributing composer via SourceControl easier as I can now .gitignore the composer.phar without needing an extra setup step of downloading composer.

I also deal with allow_url_fopen and suhosin settings, both are things my local Sysadmin dept makes our servers use. If nothing else, it is a demonstrator on how to make one-time security exceptions for people.

[tamas-marton]

Hi, I've had the same issue, and think I've found the cause. I'm using a wrapper bash script for security reasons, which applies an open_basedir restriction, allowing only all the necessary paths. One of them is: $HOME/.cache/composer/, but an error always occured, telling me that $HOME/.cache/composer/.htaccess is unreachable due to the open_basedir restriction.

I've found out that it happens also, when the $HOME/.cache/composer dir doesn't exist (for example after running composer clear-cache in my case). Manually creating the dir resolved the issue for me.

I don't know if it's already resolved in later Composer versions, sorry if it's a duplicate. By the way, my composer --version outputs the following:

Composer version 1.7.3 2018-11-01 10:05:06

[tamas-marton]

Hi, I've had the same issue, and think I've found the cause. I'm using a wrapper bash script for security reasons, which applies an open_basedir restriction, allowing only all the necessary paths. One of them is: $HOME/.cache/composer/, but an error always occured, telling me that $HOME/.cache/composer/.htaccess is unreachable due to the open_basedir restriction.

I've found out that it happens also, when the $HOME/.cache/composer dir doesn't exist (for example after running composer clear-cache in my case). Manually creating the dir resolved the issue for me.

I don't know if it's already resolved in later Composer versions, sorry if it's a duplicate. By the way, my composer --version outputs the following:

Composer version 1.7.3 2018-11-01 10:05:06

[tamas-marton]

Hi, I've had the same issue, and think I've found the cause. I'm using a wrapper bash script for security reasons, which applies an open_basedir restriction, allowing only all the necessary paths. One of them is: $HOME/.cache/composer/, but an error always occured, telling me that $HOME/.cache/composer/.htaccess is unreachable due to the open_basedir restriction.

I've found out that it happens also, when the $HOME/.cache/composer dir doesn't exist (for example after running composer clear-cache in my case). Manually creating the dir resolved the issue for me.

I don't know if it's already resolved in later Composer versions, sorry if it's a duplicate. By the way, my composer --version outputs the following:

Composer version 1.7.3 2018-11-01 10:05:06

[tamas-marton]

Hi, I've had the same issue, and think I've found the cause. I'm using a wrapper bash script for security reasons, which applies an open_basedir restriction, allowing only all the necessary paths. One of them is: $HOME/.cache/composer/, but an error always occured, telling me that $HOME/.cache/composer/.htaccess is unreachable due to the open_basedir restriction.

I've found out that it happens also, when the $HOME/.cache/composer dir doesn't exist (for example after running composer clear-cache in my case). Manually creating the dir resolved the issue for me.

I don't know if it's already resolved in later Composer versions, sorry if it's a duplicate. By the way, my composer --version outputs the following:

Composer version 1.7.3 2018-11-01 10:05:06