Il est primordial d’accorder les bonnes permissions aux fichiers et dossiers d’un site sur un serveur web. Si ces permissions sont trop permissives, l’administrateur du site s’expose à la compromission du site, voire du serveur.
Sous WordPress, c’est la même chose : les fichiers et dossiers du site doivent avoir les bonnes permissions.
Le problème : des permissions trop larges
Sur le site, j’ai eu pendant trop longtemps un problème avec les fichiers et répertoires de thèmes ou de plugins.
Je m’explique : à chaque fois qu’un plugin voulait créer des fichiers (dans un répertoire /cache
par exemple), la seule solution était de mettre les permissions de ce répertoire à 777, le mal absolu puisque cela permet au monde entier de lire, écrire et exécuter des fichiers dans ce dossier.
Pour les fichiers de thèmes éditables par WordPress, il fallait que leurs permissions soient à 666, ce qui là aussi posait un gros souci de sécurité.
Voici donc un tuto pour apprendre comment mettre les bonnes permissions à vos fichiers et dossiers pour votre site, qu’il tourne sous WordPress ou non.
Étape 1 : définir le bon propriétaire et groupe pour les fichiers
Les fichiers du site doivent appartenir au propriétaire et au groupe qui les fait tourner.
En règle générale; les serveurs de fichiers (comme Apache ou NginX) ont comme propriétaire www-data
et comme groupe groupe www-data
.
Dans mon cas, ayant installé les fichiers via SSH, les fichiers étaient détenus par l’utilisateur root
. Je crée donc un nouvel utilisateur pour mon site:
adduser caddy www-data
Je vais donc assigner à l’utilisateur caddy
et au groupe www-data
la permission d’être propriétaire de mes fichiers, avec la commande chown
.
caddy
pour le nom de votre utilisateur web ou FTP.chown
(change owner en anglais) est utilisé de manière récursive (-R
) et associe au propriétaire www-data
du groupe www-data
tous les fichiers du répertoire /home/skyminds/public_html
qui contient les fichiers du site.
Le fichier wp-config.php
Le fichier wp-config.php
doit être possédé par caddy:www-data
:
chown caddy:www-data /home/skyminds/public_html/wp-config.php
Le dossier /public_html
Le dossier /public_html
doit lui aussi être possédé par caddy:www-data
:
chown -R caddy:www-data /home/skyminds/public_html
Le dossier /wp-content et le cache FastCGI
Le dossier /public_html/wp-content
doit lui aussi être possédé par www-data:www-data
pour permettre l’upload de fichiers:
chown -R www-data:www-data /home/skyminds/public_html/wp-content
On donne les mêmes droits pour le cache FastCGI de NginX:
chown -R www-data:www-data /home/nginx-cache/*
Étape 2 : chmod, quelques explications
chmod
(change mode en anglais) est une commande qui sert à changer les permissions de lecture, d’écriture et d’exécution d’un fichier ou d’un dossier, soit en mettant plus de droits sur la cible indiquée, soit en enlevant.
Il existe 3 différentes types d’utilisateurs qui peuvent accéder à vos fichiers :
- Owner – c’est vous ou quiconque possède les droits administrateur sur le serveur.
- Group – un groupe de gens identifiés et reconnus par l’administrateur.
- Public – le reste du monde.
A ces 3 catégories d’utilisateurs s’ajoutent 3 différentes sortes d’accès/droits/permissions qu’il faut configurer :
- Read – droit de lire le fichier.
- Write – droit d’écrire et de supprimer le fichier.
- Execute – droit de lancer/exécuter un fichier ou application.
Voici un petit graphique illustrant chmod
:
Il y a les deux représentations : avec les chiffres et avec les lettres. On peut “chmoder” un fichier des deux manières mais il est plus simple de retenir les chiffres.
Le chmod peut se faire du terminal ou via un client FTP comme FileZilla : il suffit de faire un clic droit sur un fichier et de sélectionner Droits d’accès au fichier… :
Étape 3 : chmod 750 des répertoires
Les répertoires doivent avoir un chmod 750. Cela donne au propriétaire tous les droits, aux membres du groupe et aux autres les droits de lecture et d’accès.
Nous appliquons donc un chmod 750 sur tous les répertoires du site, qui n’ont pas ce niveau de permission:
find /home/skyminds/public_html -type d -not -perm 750 -exec chmod 750 {} +
Les arguments: -type d
indique que l’on recherche les directories (répertoires), -not -perm 750
indique que l’on chmode uniquement les dossiers qui n’ont pas cette permission.
Étape 4 : chmod 640 des fichiers
Les fichiers doivent traditionnellement avoir un chmod 640.
Cela donne au propriétaire les droits de modification et lecture, aux membres du groupe et au reste du monde uniquement les droits de lecture.
Nous faisons donc un chmod 640 récursif sur tous les fichiers du site :
find /home/skyminds/public_html -type f -not -perm 640 -exec chmod 640 {} +
Les arguments: -type f
indique que l’on recherche les files (fichiers), -not -perm 640
indique que l’on chmode uniquement les fichiers qui n’ont pas cette permission.
Étape 5 : chmod 440 pour wp-config.php
Enfin, on applique un chmod 440 pour notre fichier wp-config.php
, de manière à ce qu’il ne puisse être lu que par l’utilisateur et le groupe:
find /home/skyminds/public_html/wp-config.php -not -perm 440 -exec chmod 440 {} +
FAQ
Je n’arrive pas à installer ou mettre à jour des extensions ou des thèmes. On me demande de donner des identifiants FTP. Help!
Nou l’avions évoqué lors de l’article sur ftp_nlist – éditez votre fichier wp-config.php
et ajoutez-y:
if ( !defined( 'FS_METHOD' ) ):
define( 'FS_METHOD', 'direct' );
endif;
Code language: PHP (php)
Sauvegardez votre fichier et réessayez, l’installation et la mise à jour des fichiers de WordPress ainsi que les thèmes et extensions est dorénavant possible.
Conclusion
Voilà, je pense avoir tout dit. L’étape 1 est la plus importante : si ce n’est pas le bon propriétaire qui possède les fichiers (le serveur de fichier dans notre cas), les permissions sont caduques et il devient nécessaire et périlleux de donner des permissions trop grandes.
Avec le bon propriétaire des fichiers, les chmods classiques (750 pour les dossiers, 640 pour les fichiers, 440 pour wp-config.php
) passent nickel et il n’y a plus aucun souci de permissions, que ce soit pour accéder aux fichiers ou uploader des images via l’interface d’administration de WordPress.
Synopsis » Monter un serveur dédié de A à Z
- Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
- Serveur dédié : créer la base de données MySQL et importer WordPress
- Serveur dédié : créer et activer un Virtual Host sous Apache
- Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
- Serveur dédié : sécurisation des services avec iptables et fail2ban
- Serveur dédié : sécurisation de la couche TCP/IP
- Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
- Serveur dédié : sécuriser Apache 2 avec ModSecurity
- Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
- Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
- Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
- Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
- Serveur dédié : installer la dernière version d’APC par SVN
- Serveur dédié : analyse des performances du serveur
- Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
- Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
- Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
- Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
- Serveur dédié : impossible de se connecter à un port distant
- Rsync: rapatrier les fichiers du serveur à la maison
- Bash : réparer les tables MySQL en cas de crash
- Serveur dédié : création d’une seedbox avec Transmission
- Serveur dédié : des paquets LAMP à jour sous Debian
- Serveur dédié : mise à jour vers Debian 7 Wheezy
- Serveur dédié : activer X11 forwarding pour SSH
- Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
- Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
- Serveur dédié : mise en place de l’IPv6
- WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
- WordPress : héberger les images sur un sous-domaine
- Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
- Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
- Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
- Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
- Serveur dédié : configurer Webmin en TLS avec un certificat SSL
- Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
- Serveur dédié : installer et configurer Varnish 4
- Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
- Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
- Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
- Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
- Serveur dédié : installer la dernière version d’OpenSSL sous Debian
- Serveur dédié : activer l’IP canonique du serveur sous Apache
- Serveur dédié : mise à jour vers PHP 5.6
- MySQL : convertir les tables MyISAM au format InnoDB
- Serveur dédié : optimiser toutes les images GIF avec GIFsicle
- Serveur dédié : migration de MySQL vers MariaDB
- BASH : lister, bloquer et débloquer des adresses IP avec iptables
- Serveur dédié : produire une meilleure réserve d’entropie avec haveged
- Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
- Serveur dédié : mise en place du protocole DANE
- 8 règles d’or pour bien déployer DNSSEC et DANE
- Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
- Serveur dédié : optimiser la couche TCP
- Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
- Serveur dédié : mettre à jour Apache pour HTTP/2
- Serveur dédié : ajouter le domaine à la liste HSTS preload
- Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
- Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
- Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Rencontrez-vous des défis avec votre site WordPress ou WooCommerce? Laissez-moi les résoudre pour vous.
super ton article, mais quid des droits d’écriture sur les répertoire d’upload, plugins, themes etc ?
Bonjour,
Le chmod 755 suffit pour tout ce qui concerne les répertoires uploads, plugins et themes.
Salut Matt,
Oui, merci, effectivement ça fonctionne :)
en tous cas félicitations pour cet article de qualité qui manque à tout tutorial, voire même à la doc officielle et qui devrait avantageusement y être ajouté :)
avec mes meilleurs vœux de bonne continuation dans cette voie qui enrichit la communauté du libre !
un grand merci pour ce tuto très clair et qui a solutionné mon souci de droits lors d’upload de mes plugins wordpress
Thanks!!
You’re very welcome pierre! :)
Salut.
Ta solution a résolu mon problème d’uploads d’images, mais maintenant, pour pouvoir gitter les modifications, je dois passer en sudo. Je trouve ça très étonnant.
Bonjour,
Il doit y avoir une relation avec l’utilisateur utilisé pour faire les modifications.
Bonjour ,
Un grand merci car ta solution m’a dépanné mais surtout elle m’a permis d’apprendre comment gérer mes droits proprement et comprendre ce qui se passe !
Bonjour Mika,
Merci pour ton message, je suis content d’avoir pu t’aider !
Merci pour ce cours qui m’a bien rafraîchi la mémoire sur quelques détails qui m’échappaient, très bonne explication.
Bonjour,
avec les permissions 755 sur les dossiers et 644 sur les fichiers, il n’est cependant pas possible de faire les mises à jour. On repasse tout en 755 le temps d’effectuer la mise à jour, puis de nouveau 644 une fois la mise à jour effectuée ? Il n’y aurait pas plus pratique ?
Merci pour ce tuto en tout cas.
Bonjour Laurent,
On peut tout à fait faire les mises à jours avec les dossiers à 755 et les fichiers à 644, ce sont les permissions de base recommandées.
Si la mise à jour est impossible, il faut alors vérifier que le serveur de fichier (
www-data
généralement) a bien les droits sur les fichiers. Il faut alors se tourner vers la commandechown
.Bonjour,
Je suis tombé sur votre post qui date de 2014, lors d’une recherche concernant un problème que j’ai en localhost de suppression impossible d’une extension, alors que j’ai www-data en groupe de mes dossiers et fichiers et les droits 755 sur les dossiers et 644 sur les fichiers.
N’est-il pas dangereux de proposer de mettre en propriétaire www-data sur tous les dossiers et fichiers du site pour ensuite affecter 755 ou 644 aux dossiers et fichiers ?
Cela ne revient-il pas à permettre à www-data de faire tout ce qu’il veut ? (écriture entre autre)
Merci par avance
Bonjour Calou82,
Je viens de mettre à jour l’article avec plusieurs changements:
– permssions des dossiers à 750
– permission des fichiers à 640
– permission de wp-config.php
Les fichiers doivent appartenir à un utilisateur linux, si possible autre que `www-data`. J’ai rajouté une partie là-dessus aussi.
Matt