PHP

« require_once(‘monfichier.phar’); » et puis plus rien. WTF ?!

Flattr this!

Il y a quelques soirs, je testais une classe sous atoum avec mon pote m0hda (oui on se fait des soirées code, faut bien apprendre de nouvelles choses) et à l'exécution, voilà le résultat qu'on obtenait avec CLI :

 

dev [/var/www] > php ./tests/totoTest.php
3
7
bool(true)
dev [/var/www] >

L'exécution du script php s'arrête comme ça, sans erreur et sans avoir fini. Notre fichier de tests (qu'on a simplifié pour illustrer ce billet) :

 

 

<?php
namespace {
echo __LINE__."\n"; // 3
use \mageekguy\atoum;

require __DIR__.'/../classes/toto.php';
echo __LINE__."\n"; // 7
var_dump(file_exists(__DIR__.'/atoum/mageekguy.atoum.phar'));
require __DIR__.'/atoum/mageekguy.atoum.phar';
echo __LINE__."\n"; // 10
}
?>

Rah mince, que se passe-t'il ? Le chemin est bon puisque file_exists() nous confirme que le fichier existe. Et pourtant le code s'arrête net sans message, sans erreur, sans exception au moment du require_once.

 

Le contexte

On utilisait un serveur Debian tout frais, avec PHP 5.3.8 réglé par défaut en configuration de développement. C'est à dire avec PHAR 2.0.1 actif, display_errors à On et la consigne pour les erreurs est E_ALL | E_STRICT.

On s'est même volontairement amusés à glisser des erreurs de syntaxe, pour voir, pas de soucis, PHP nous les crachait bien.

La solution

Allez fouiller dans votre fichier syslog, vous aurez un équivalent de ce message :

suhosin ALERT - Include filename ('phar://mageekguy.atoum.phar/classes/autoloader.php') is an URL that is not allowed (attacker 'REMOTE_ADDR not set', file '/var/www/tests/atoum/mageekguy.atoum.phar', line 16)

Ce qui signifie un truc bête. Suhosin n'autorise pas PHAR par défaut. Eh eh pas de bol. Rajoutez donc ceci n'importe où dans votre fichier php.ini :

 

suhosin.executor.include.whitelist="phar"

Bizarrement ça marche mieux 😉

Pour apprendre de ses erreurs, il faut les comprendre

Qu'est-ce que suhosin ? C'est un système de sécurité pour PHP distribué par défaut avec PHP dans les distributions comme Debian ou encore Ubuntu. Celui-ci permet de protéger un serveur PHP en bloquant ou limitant certains usages.

Il a très bien fait son boulot en somme. Et ici la solution est de lui dire que les appels à PHAR sont autorisés. Pour info Suhosin possède une whitelist et une blacklist. Elles sont contrôlées dans cet ordre, le contrôle s'arrête dès que l'élément cherché est trouvé. Si PHAR est présent dans les deux listes, il sera autorisé.

En espérant que ça vous servira et que ça vous évitera de regarder avec l'air aussi abruti et décontenancé qu'on avait tous les deux face à ce souci. Ou comme me l'a très bien suggéré mageekguy quand je lui ai parlé du problème : RTFM 😉

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans PHP, avec comme mot(s)-clef(s) , , , , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • http://blog.mageekbox.net mageekguy

    Un lien vers la documentation de atoum, qui donne la solution à ce problème dans la section Troubleshooting, aurait été mieux qu’un lien vers mon tweet ;).

    • http://www.mathieurobin.com/ Mathieu

      C’est vrai. D’ailleurs on a ri jaune quand on a vu tes slides le lendemain avec première slide technique, première ligne : la solution. On s’est dit que définitivement, RTFM est un bon conseil 😉 Merci à toi d’avoir précisé le lien de ta doc !

Articles liés