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

chmod-007-permis-executer-300Sur 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 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.

Etape 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. Si votre site tourne sous Apache, le propriétaire est www-data et le groupe www-data.

Dans mon cas, ayant installé les fichiers via SSH, les fichiers étaient détenus par l’utilisateur root. Il faut donc les redonner à Apache avec la commande chown.

Dans le terminal, tapez :

 chown -R www-data:www-data /home/skyminds/public_html 

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.

Etape 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 :

  1. Owner – c’est vous ou quiconque possède les droits administrateur sur le serveur.
  2. Group – un groupe de gens identifiés et reconnus par l’administrateur.
  3. Public – le reste du monde.
A lire :  Easy Chords : retranscrire automatiquement une chanson jouée dans Winamp en tablature ou en accords

A ces 3 catégories d’utilisateurs s’ajoutent 3 différentes sortes d’accès/droits/permissions qu’il faut configurer :

  1. Read – droit de lire le fichier.
  2. Write – droit d’écrire et de supprimer le fichier.
  3. Execute – droit de lancer/exécuter un fichier ou application.

Voici un petit graphique illustrant chmod :

chmod-representation

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… :

chmod-permissions

Etape 3 : chmod 755 des répertoires

Les répertoires doivent avoir un chmod 755. 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 755 sur tous les répertoires du site :

find /home/skyminds/public_html -type d -exec chmod 755 {} +

L’argument -type d indique que l’on recherche les directories (répertoires).

Etape 4 : chmod 644 des fichiers

Les fichiers doivent traditionnellement avoir un chmod 644. 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 644 récursif sur tous les fichiers du site :

find /home/skyminds/public_html -type f -exec chmod 644 {} +

L’argument -type f indique que l’on recherche les files (fichiers).

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 Apache 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 (644 pour les fichiers, 755 pour les dossiers) passent nickel et il n’y a plus aucun souci de permissions.

Si vous avez trouvé une faute d’orthographe, veuillez nous en informer en sélectionnant le texte en question et en appuyant sur Ctrl + Entrée.

Vous souhaitez réaliser un nouveau projet WordPress ou WooCommerce, ou ajouter de nouvelles fonctionnalités? Ou améliorer les performances de votre site?

Parlons de votre projet »

A lire :  Nouveau serveur dédié : migration vers ORION

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. 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
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
A lire :  Serveur dédié : configurer Webmin en TLS avec un certificat SSL

Articles en rapport:

12 Comments

  1. Avatar

    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.

    • Matt

      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 commande chown.

  2. Avatar

    Merci pour ce cours qui m’a bien rafraîchi la mémoire sur quelques détails qui m’échappaient, très bonne explication.

  3. Avatar

    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 !

    • Matt

      Bonjour Mika,

      Merci pour ton message, je suis content d’avoir pu t’aider !

  4. Avatar

    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.

    • Matt

      Bonjour,

      Il doit y avoir une relation avec l’utilisateur utilisé pour faire les modifications.

  5. Avatar

    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!!

  6. Avatar
    SkyLight33 Reply

    super ton article, mais quid des droits d’écriture sur les répertoire d’upload, plugins, themes etc ?

    • Matt

      Bonjour,

      Le chmod 755 suffit pour tout ce qui concerne les répertoires uploads, plugins et themes.

      • Avatar
        SkyLight33

        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 !

Écrire un commentaire

Spelling error report

The following text will be sent to our editors: