Permissions de fichiers WordPress : que signifient 755 et 644 ?

Les valeurs 755 et 644 circulent dans toutes les documentations sans que grand monde ne sache ce qu'elles décrivent réellement. On les applique, le site fonctionne, et l'on passe à autre chose. Puis un jour une mise à jour échoue, un téléversement est refusé, ou un audit signale des droits trop larges, et il faut bien comprendre. Les permissions de fichiers sous WordPress reposent sur un mécanisme simple, hérité des systèmes de type Unix, dont la lecture s'apprend en cinq minutes. Le point le plus important n'est d'ailleurs pas la valeur elle même mais l'identité du propriétaire, qui détermine à qui ces droits s'appliquent.

Lire les trois chiffres

Le mécanisme distingue trois catégories d'utilisateurs et trois types d'actions, ce qui donne neuf informations résumées en trois chiffres. Le fonctionnement général des commandes correspondantes est décrit dans notre article sur chmod et chown sous Linux.

Trois catégories

Le premier chiffre concerne le propriétaire du fichier, le deuxième le groupe auquel il appartient, le troisième tous les autres utilisateurs du système. Cette distinction est fondamentale : donner un droit au propriétaire n'a rien à voir avec le donner à tout le monde. Sur un hébergement mutualisé, la troisième catégorie inclut potentiellement les autres sites hébergés sur la même machine, ce qui explique pourquoi les droits accordés aux autres méritent une attention particulière. Sur un serveur dédié où seul le site tourne, cette troisième catégorie ne recouvre presque personne, ce qui change la lecture du risque.

Trois actions

Chaque chiffre additionne trois valeurs : quatre pour la lecture, deux pour l'écriture, une pour l'exécution. Un chiffre de sept vaut donc lecture, écriture et exécution ; un chiffre de cinq vaut lecture et exécution ; un chiffre de quatre vaut lecture seule. Cette addition rend la lecture immédiate une fois qu'on la connaît, et elle explique pourquoi certaines valeurs paraissent arbitraires alors qu'elles sont parfaitement logiques. Six vaut lecture et écriture, sans exécution, ce qui convient exactement à un fichier de données. Une fois cette addition comprise, n'importe quelle valeur se déchiffre en quelques secondes sans avoir à consulter de tableau.

Ce que signifie l'exécution sur un répertoire

Sur un fichier, le droit d'exécution permet de le lancer comme un programme. Sur un répertoire, il signifie tout autre chose : il permet de le traverser, c'est à dire d'accéder à ce qu'il contient. C'est la raison pour laquelle les répertoires portent un droit d'exécution que les fichiers n'ont pas, différence qui déroute systématiquement et qui explique la valeur de sept cent cinquante cinq sur les répertoires face à six cent quarante quatre sur les fichiers. Un répertoire sans droit de traversée rend inaccessible tout ce qu'il contient, quels que soient les droits des fichiers qui s'y trouvent.

Décomposer sept cent cinquante cinq

Le propriétaire dispose de la lecture, de l'écriture et de la traversée. Le groupe et les autres disposent de la lecture et de la traversée, sans écriture. Appliquée à un répertoire, cette valeur signifie que seul le propriétaire peut y créer ou y supprimer des fichiers, alors que tout le monde peut lister son contenu et y accéder. C'est la valeur standard pour les répertoires d'un site web, puisque le serveur doit pouvoir traverser l'arborescence pour servir les fichiers. Elle convient aussi bien à un hébergement mutualisé qu'à un serveur dédié, à condition que le propriétaire soit correctement choisi.

Décomposer six cent quarante quatre

Le propriétaire peut lire et écrire, le groupe et les autres peuvent seulement lire. Aucune catégorie ne dispose du droit d'exécution, ce qui est parfaitement correct pour un fichier PHP : celui ci n'est pas exécuté par le système mais lu par l'interpréteur, qui n'a besoin que du droit de lecture. Cette subtilité explique pourquoi il ne faut jamais mettre un fichier PHP en sept cent cinquante cinq, valeur que l'on rencontre pourtant régulièrement sur les installations réglées à la hâte. Un fichier PHP exécutable ne présente pas de risque immédiat et signale surtout que les droits ont été appliqués sans distinction de type.

Les valeurs à ne jamais employer

La valeur de sept cent soixante dix sept accorde tous les droits à tout le monde, y compris l'écriture par n'importe quel utilisateur du système. Sur un hébergement partagé, cela signifie qu'un autre site compromis peut modifier vos fichiers. Cette valeur est pourtant conseillée dans quantité de forums comme solution rapide à un problème de téléversement, ce qui en fait probablement le plus mauvais conseil circulant sur le sujet. Il existe toujours une solution propre, qui passe par le propriétaire plutôt que par l'élargissement des droits. Le temps gagné par le raccourci se paie invariablement plus tard, et beaucoup plus cher.

Le propriétaire compte plus que la valeur

C'est le point que les documentations passent sous silence et qui explique la plupart des situations bloquées, où l'on augmente les droits faute de comprendre le vrai problème.

Qui possède les fichiers

Chaque fichier appartient à un utilisateur et à un groupe du système. Sur un serveur web, deux identités entrent en jeu : celle sous laquelle tourne le serveur, et celle du compte employé pour déposer les fichiers. Lorsque ces deux identités diffèrent et que les droits n'accordent l'écriture qu'au propriétaire, le serveur ne peut rien écrire, ce qui produit exactement les symptômes que l'on attribue à tort à des permissions trop restrictives.

La bonne configuration

La configuration recommandée consiste à donner la propriété des fichiers au compte de déploiement et à faire appartenir ces fichiers au groupe du serveur web, avec un droit de lecture pour le groupe. Le serveur lit tout, n'écrit rien, sauf dans les répertoires où on lui accorde explicitement l'écriture. Cette organisation limite considérablement les dégâts d'une compromission, un script malveillant exécuté par le serveur ne pouvant pas modifier le code du site. C'est probablement la mesure de durcissement la plus efficace que l'on puisse appliquer à une installation WordPress.

Le cas du répertoire de téléversement

C'est le seul endroit où le serveur doit pouvoir écrire en fonctionnement normal, pour enregistrer les images et les documents déposés depuis l'administration. Ce répertoire doit donc appartenir au serveur web ou lui accorder l'écriture par le groupe. En contrepartie, il ne doit contenir aucun fichier exécutable, ce qui se garantit par une règle de configuration interdisant l'exécution dans cette arborescence, précaution qui ferme une voie d'attaque classique. Cette règle se pose au niveau du serveur web et vaut pour l'ensemble de l'arborescence de téléversement, sous répertoires compris.

Les mises à jour automatiques

WordPress met à jour son cœur et ses extensions en écrivant directement dans ses répertoires, ce qui suppose que le serveur y ait le droit d'écriture. Sur une configuration verrouillée, ces mises à jour échouent et proposent une saisie d'identifiants de transfert de fichiers. Deux voies existent alors : accorder temporairement l'écriture, ou gérer les mises à jour en ligne de commande depuis le compte de déploiement, méthode nettement préférable et décrite dans notre article sur la manière d'installer WordPress en ligne de commande sur un VPS. La seconde voie suppose en contrepartie que quelqu'un lance ces mises à jour régulièrement, engagement qu'il faut prendre consciemment.

Le cas des hébergements mutualisés

Sur la plupart des mutualisés modernes, le serveur web tourne sous l'identité du compte client, ce qui simplifie tout : le propriétaire est le même partout et les droits standard suffisent. C'est la raison pour laquelle les problèmes de permissions se rencontrent surtout sur les serveurs gérés en propre, où la séparation des identités doit être décidée et configurée. Sur ces hébergements, une valeur de sept cent soixante dix sept n'apporte rien et augmente inutilement le risque. Les valeurs standard suffisent et il n'y a jamais de raison de s'en écarter sur ce type d'hébergement.

Le fichier de configuration

Le fichier contenant les identifiants de connexion à la base mérite un traitement plus strict que les autres. Une valeur de six cent quarante, accordant la lecture au groupe et rien aux autres, convient bien lorsque le serveur appartient au groupe. Une valeur de six cents, réservant tout au propriétaire, convient lorsque le serveur est le propriétaire. Dans les deux cas, aucun autre utilisateur du système ne doit pouvoir lire ce fichier, exigence élémentaire trop souvent négligée. Le déplacer d'un niveau au dessus de la racine servie, lorsque l'hébergement le permet, ajoute une protection supplémentaire sans inconvénient.

Régler et vérifier

Les commandes sont simples et quelques précautions évitent de casser une installation en une ligne.

Appliquer par type

La bonne méthode consiste à appliquer une valeur aux répertoires et une autre aux fichiers, en parcourant l'arborescence avec un filtre sur le type. Appliquer une valeur unique à tout casse soit la traversée des répertoires, soit rend les fichiers exécutables. Cette distinction s'obtient avec une option de la commande de recherche, en deux lignes, et elle constitue la manière correcte de reprendre une installation dont les droits sont incohérents. Elle doit être lancée depuis la racine du site et non depuis un répertoire parent, précaution qui évite bien des dégâts.

Corriger la propriété

Le changement de propriétaire demande des privilèges d'administration et ne peut donc être fait que sur un serveur dont on dispose. Sur un mutualisé, cette question ne se pose pas. La commande s'applique récursivement à l'arborescence et doit être exécutée avant l'ajustement des droits, l'ordre inverse produisant un état transitoire où le serveur ne peut plus rien lire. Sur un site en production, cet état transitoire dure quelques secondes et se traduit par des erreurs visibles.

Vérifier ce qui est en place

Une commande de recherche listant les fichiers dont les droits diffèrent des valeurs attendues donne immédiatement la liste des anomalies. Ce contrôle prend quelques secondes et il révèle généralement quelques dizaines de fichiers déposés par un transfert mal configuré, un extrait d'archive ou une intervention ancienne. Il mérite d'être relancé après chaque intervention manuelle sur les fichiers du site. Il peut également être automatisé et intégré aux contrôles périodiques du serveur.

Chercher les droits trop larges

La recherche des éléments accessibles en écriture par tous constitue le contrôle de sécurité le plus rapide qui soit. Tout résultat doit être examiné et corrigé, sans exception, y compris lorsque la valeur a été posée volontairement pour régler un problème dont on a oublié la nature. Ce contrôle figure parmi ceux que nous recommandons dans notre article sur l'audit de sécurité d'un site WordPress. Il se lance en une commande et son résultat devrait être vide sur une installation correctement réglée.

Contrôler après un transfert

Les clients de transfert de fichiers appliquent leurs propres valeurs par défaut, souvent différentes de celles du serveur. Un dépôt effectué depuis un poste de travail peut donc produire des fichiers en six cents, illisibles par le serveur, ou en sept cent soixante dix sept selon la configuration du client. Un contrôle après chaque transfert massif évite de chercher pendant une heure pourquoi une page renvoie une erreur d'accès refusé. La plupart des clients permettent de fixer ces valeurs par défaut dans leurs réglages, ce qui règle la question une fois pour toutes.

Ne pas appliquer aveuglément

Une commande récursive lancée depuis le mauvais répertoire modifie les droits de l'ensemble du serveur et peut le rendre inutilisable. La précaution consiste à vérifier le répertoire courant avant, à afficher la liste des fichiers concernés avant de les modifier, et à disposer d'une sauvegarde. Ces trois réflexes tiennent en trente secondes et évitent l'incident le plus spectaculaire que l'on puisse produire en une seule ligne de commande.

Diagnostiquer les problèmes courants

Trois ou quatre symptômes reviennent constamment, et chacun se rattache à une cause précise qu'il est facile d'identifier une fois le mécanisme compris.

Le téléversement refusé

Une image que l'administration refuse d'enregistrer signale que le serveur ne peut pas écrire dans le répertoire de téléversement. La cause est presque toujours un problème de propriétaire et non de valeur : le répertoire appartient au compte de déploiement et le serveur n'a que la lecture. La correction consiste à ajuster la propriété ou le groupe, pas à passer le répertoire en écriture pour tous, réflexe malheureusement répandu.

La demande d'identifiants de transfert

Lorsque WordPress affiche un formulaire demandant des identifiants au moment d'une mise à jour, c'est qu'il a constaté ne pas pouvoir écrire directement. Ce comportement est un repli et non une exigence. Le traiter en accordant l'écriture au serveur fonctionne, le traiter en effectuant les mises à jour en ligne de commande est plus propre et plus sûr. Le choix entre les deux dépend de qui administre le site au quotidien.

L'erreur d'accès refusé

Une page renvoyant une erreur d'accès refusé sur un fichier existant signale que le serveur ne peut pas le lire, soit parce que le fichier lui même est trop restrictif, soit parce qu'un répertoire parent n'est pas traversable. Ce second cas est le plus déroutant : le fichier a des droits corrects et reste inaccessible. La vérification doit donc remonter toute l'arborescence, du fichier jusqu'à la racine du site.

Le fichier de configuration inaccessible

Un site affichant une erreur de connexion à la base alors que les identifiants sont corrects peut simplement ne pas pouvoir lire son fichier de configuration. Un réglage trop strict, appliqué par excès de prudence, produit exactement ce symptôme. La valeur retenue doit toujours permettre la lecture par l'identité sous laquelle tourne le serveur, contrainte qui rend nécessaire de connaître cette identité avant de resserrer quoi que ce soit.

Les fichiers apparus après une compromission

Des fichiers appartenant au serveur web dans des répertoires qui devraient appartenir au compte de déploiement signalent une écriture par le site lui même, donc potentiellement par un script malveillant. Cette recherche par propriétaire est l'un des indices les plus fiables lors d'un diagnostic d'infection. Elle demande simplement de savoir quelle est la propriété normale, information qu'il vaut mieux avoir notée avant l'incident. Un relevé de la propriété normale, conservé avec la documentation du site, transforme cette recherche en comparaison immédiate.

Documenter la configuration retenue

Les valeurs appliquées, l'identité du serveur, celle du compte de déploiement et les répertoires accessibles en écriture doivent tenir dans une note de cinq lignes conservée avec le projet. Cette note transforme un diagnostic d'une heure en vérification de deux minutes, et elle permet à quelqu'un d'autre d'intervenir sans avoir à reconstituer la configuration. C'est le genre de document que l'on n'écrit jamais et que l'on cherche toujours au moment de l'incident. Elle se range avec les accès d'hébergement, endroit où on la cherchera naturellement, et non dans la documentation fonctionnelle du site.