Penchons nous sur un test, avec un oeil orienté “sécurité”, du célèbre CMS spip.
Je teste donc la version 2.1.8. Lors de l’installation, spip m’indique que quelques répertoires doivent offrir au processus “apache” les droits en écriture. Ce n’est pas délirant, dans la mesure où la publication se fait en ligne : je vais y injecter des images, etc.
J’applique donc la règle du “privilège le plus faible” traditionnelle des systèmes de fichiers unix : j’assigne à ces repertoires le groupe apache, et en accordant à ce groupe les droits en écriture :
chgrp www-data IMG/ tmp/ local/ config/
chmod g+w IMG/ tmp/ local/ config/
L’installation terminée, je crée une rubrique, un article, et j’y colle une photo pour voir le résultat.
Le résultat, le voici : une image est bien ajoutée dans le répertoire IMG/ avec les droits en 666.
De nombreux fichiers de spip sont automatiquement passés en droits 666 ou 777, dans les installations par défaut. Y compris des fichiers PHP executés par le serveur web.
Franchement, ça fait peur.
J’ai trouvé une solution simple : remettre un chmod global à une valeur plus saine de manière globale pour spip.
Éditez votre fichier ecrire/mes_options.php, et posez-y le code suivant :
define(‘_SPIP_CHMOD’, 0770);
ou mieux
define(‘_SPIP_CHMOD’, 0570);
Le serveur web aura ainsi les droits de lire les fichiers, et son groupe les droits de lire et modifier ces fichiers.

Je reste tout de même estomaqué de voir un logiciel aussi populaire faire la bêtise monumentale du “chmod 777”, qui est comme chacun le sait réputée pour être la bêtise traditionnelle du newbie.
Pour référence, en sécurité, on ne doit JAMAIS positionner les droits 666 ou 777 sur un fichier, c’est une hérésie, et on a TOUJOURS une meilleure solution. La littérature à ce sujet ne manque pas : commencer par cet article sur la Séparation des privilèges