suEXEC et les liens symboliques

suEXEC et les liens symboliques

Je suis chez OVH depuis bientôt 4,5 ans. J’apprécie leur fiabilité, par contre j’ai toujours été un peu déçu par la documentation. En fait, OVH c’est un peu le Free de l’hébergement : c’est top quand ça marche, après c’est un peu plus compliqué… Pour finir sur OVH, car ce n’est pas l’objet de ce billet, j’ai le sentiment d’un changement de stratégie commercial qui me fait douter sur la pérennité de mon abonnement chez eux.

Revenons-en à nos moutons. OVH implémente suEXEC sur ses hébergements mutualisés (sûrement à leur sauce). La documentation de suEXEC n’est pas des plus claire et elle a toujours manqué d’exemple. Enfin, on trouve encore moins d’information sur le site d’OVH.

Ce billet présente divers tests afin de mieux comprendre ce qu’on peut faire et ne pas faire quand suEXEC est activé.

Présentation du banc de test

Création chez OVH de 3 sous-domaines :

  • pipo.e-gaulue.com pointe vers le répertoire /pipo dans le ftp fourni par OVH
  • molo.e-gaulue.com pointe vers le répertoire /molo dans le ftp fourni par OVH
  • rato.e-gaulue.com pointe vers le lien symbolique /rato qui pointe à son tour vers le répertoire /pipo

Création de répertoire et de liens symboliques selon le schéma suivant :

/
+- pipo -+    
|        +- index.php
|        +- index2.php -> index.php
|        +- banga -> .
|        +- yadelo -+
|                   +- index.php -> ../index.php
|
+- molo -+
|        +- index.php -> ../pipo/index.php
|        +- pipo -> ../pipo
|
+- rato -> pipo

index.php est un fichier qui contient juste <?php phpinfo(); ?>.
Pour éviter tout effet de bord, il n’y a aucun fichier .htaccess dans ces répertoires.

Résultats des tests

  • http://pipo.e-gaulue.com/ : OK
  • http://pipo.e-gaulue.com/index.php : OK
  • http://pipo.e-gaulue.com/inedx2.php : suEXEC ERROR
  • http://pipo.e-gaulue.com/banga : OK
  • http://pipo.e-gaulue.com/banga/index.php : OK
  • http://pipo.e-gaulue.com/banga/index2.php : suEXEC ERROR
  • http://pipo.e-gaulue.com/banga/../index.php : OK
  • http://pipo.e-gaulue.com/yadelo : suEXEC ERROR
  • http://pipo.e-gaulue.com/yadelo/index.php : suEXEC ERROR
  • http://pipo.e-gaulue.com/yadelo/../index.php : OK
  • http://molo.e-gaulue.com/ : suEXEC ERROR
  • http://molo.e-gaulue.com/index.php : suEXEC ERROR
  • http://molo.e-gaulue.com/pipo : OK
  • http://molo.e-gaulue.com/pipo/index.php : OK
  • http://molo.e-gaulue.com/pipo/index2.php : suEXEC ERROR
  • http://molo.e-gaulue.com/pipo/../index.php : suEXEC ERROR
  • http://rato.e-gaulue.com/ : OK
  • http://rato.e-gaulue.com/index.php : OK
  • http://rato.e-gaulue.com/banga : OK
  • http://rato.e-gaulue.com/banga/index.php : OK
  • http://rato.e-gaulue.com/banga/../index.php : OK
  • http://rato.e-gaulue.com/yadelo : suEXEC ERROR
  • http://rato.e-gaulue.com/yadelo/index.php : suEXEC ERROR
  • http://rato.e-gaulue.com/yadelo/../index.php : OK

Conclusions

Elles sont maigres d’autant que les logs OVH ne sont pas bavards.

[Wed Jan 11 08:06:16 2012] [error] [client 82.245.81.32] [host pipo.e-gaulue.com] suexec policy violation: see suexec log for more details

Je n’ai jamais réussi à trouver ces fameux logs.

Déjà, on peut constater que les références arrière (/../) sont certainement analysées par apache bien avant la transmission à suEXEC (ça ne vient pas du navigateur utilisé car je l’ai vérifié aussi en telnet).

Ensuite, suEXEC tolère de suivre des liens symboliques vers des répertoires (qu’ils contiennent ou non des références arrières) mais pas vers des scripts. S’agit-il du comportement de la règle 4 de suEXEC, dans ce cas : pourquoi les liens symboliques sur les répertoires fonctionnent ? Par ailleurs, le script est censé fonctionner tant qu’on reste dans le répertoire spécifié par --with-suexec-docroot. Mais quel est ce répertoire : il est impossible de lancer la commande suexec -V en tant que root sur le serveur mutualisé.

En tout cas tout ceci est assez pénalisant. J’attends l’avis d’OVH intérogé sur le sujet.

Réponse d’OVH et conclusions définitives

Après quelques échanges peu productifs avec le support OVH, une réponse assez peu documentée mais vrai, a fini par tomber : « […]Par contre à savoir que par défaut, les liens symboliques ne peuvent se faire que sur un dossier et non un fichier d’où l’erreur avec votre lien vers le fichier index.php[…]».

Comme en définitive je ne suis pas certain que mon correspondant sache d’où ca vient et qu’il m’a fallu à moi-même un peu de temps avant de trouver une réponse documentée, je la redonne :

If you know a little c, then reading the suexec.c source code makes
things clear:
/*
* Error out if we cannot stat the program.
*/
if (((lstat(cmd, &prg_info)) != 0) || (S_ISLNK(prg_info.st_mode))) {
log_err(« cannot stat program: (%s)\n », cmd);
exit(117);
}

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *