Dans les systèmes de fichiers informatiques, fichiers et répertoires disposent de différentes permissions qui spécifient qui peut y accéder ainsi que le type d’accès possible, suivant qu’il s’agisse de lire, écrire, modifier ou accéder aux fichiers. Ceci est important parce que certaines fonctionnalités de WordPress peuvent avoir besoin d’écrire dans les fichiers de votre répertoire wp-content.
Modes de permissions
7 5 5
propriétaire groupe autres
r+w+x r+x r+x
4+2+1 4+0+1 4+0+1 = 755
Le mode de calcul des permissions se fait en additionnant chacune des valeurs pour le propriétaire, pour les utilisateurs et utilisatrices du groupe, et pour tous les autres types d’accès. Le diagramme ci-dessous vous explique comment.
- Read = 4 : Autorise la lecture du fichier.
- Write = 2 : Autorise l’écriture et la modification du fichier.
- eXecute = 1 : Autorise l’exécution d’un fichier ou l’accès à un répertoire.
7 4 4 user group world r+w+x r r 4+2+1 4+0+0 4+0+0 = 744
7 4 4
propriétaire groupe autres
r+w+x r r
4+2+1 4+0+0 4+0+0 = 744
Exemples de modes de permission
| Mode | Chaînes de permissions | Explication |
|---|---|---|
| 0477 | -r–rwxrwx | Le propriétaire a les accès en lecture (4), le groupe et les autres ont lecture/écriture/exécution (7). |
| 0677 | -rw-rwxrwx | Le propriétaire a les accès en lecture/écriture (6), le groupe et les autres ont lecture/écriture/exécution (7). |
| 0444 | -r–r–r– | Tous ont seulement un accès en lecture (4). |
| 0666 | -rw-rw-rw- | Tous ont un accès en lecture/écriture (6). |
| 0400 | -r——– | Le propriétaire a seulement accès en lecture (4), le groupe et les autres n’ont aucun accès (0). |
| 0600 | -rw——- | Le propriétaire a les accès en lecture/écriture (6), le groupe et les autres n’ont aucun accès (0). |
| 0470 | -r–rwx— | Le propriétaire a seulement accès en lecture (4), le groupe en lecture/écriture/exécution (7), les autres n’ont aucun accès (0). |
| 0407 | -r—–rwx | Le propriétaire a seulement accès en lecture (4), le groupe n’a aucun accès (0), les autres ont lecture/écriture/exécution (7). |
| 0670 | -rw-rwx— | Le propriétaire a les accès en lecture/écriture (6), le groupe en lecture/écriture/exécution (7), les autres n’ont aucun accès (0). |
| 0607 | -rw—-rwx | Le propriétaire a les accès en lecture/écriture (6), le groupe n’a aucun accès (0), les autres ont lecture/écriture/exécution (7). |
Schéma des permissions pour WordPress
Les permissions seront différentes d’un hébergeur à l’autre, ce guide ne détaille donc que les principes généraux. Il ne peut pas couvrir tous les cas. Ce guide s’applique aux serveurs exécutant une configuration standard (à noter, pour l’hébergement mutualisé utilisant les méthodes « suexec », voir ci-dessous).
En règle générale, tous les fichiers doivent appartenir à votre compte utilisateur (FTP) sur votre serveur web et doivent être accessibles en écriture par ce compte. Sur les hébergements mutualisés, les fichiers ne doivent jamais appartenir au processus du serveur web lui-même (parfois, il s’agit de www, d’apache, ou nobody).
Tout fichier nécessitant un accès en écriture à partir de WordPress doit appartenir au compte utilisateur utilisé par WordPress (qui peut être différent du compte du serveur) ou appartenant au groupe.
Par exemple, vous pouvez avoir un compte utilisateur qui vous permet de gérer des fichiers FTP dans les deux sens vers votre serveur, mais votre serveur lui‑même peut s’exécuter en utilisant un compte distinct, dans un groupe d’utilisateurs distinct, tel que dhapache ou nobody.
Si WordPress fonctionne en tant que compte FTP, ce compte doit avoir un accès en écriture, c’est-à-dire être le propriétaire des fichiers ou appartenir à un groupe disposant d’un accès en écriture.
Dans ce dernier cas, cela signifierait que les autorisations sont définies de manière plus permissive que la valeur par défaut (par exemple, 775 au lieu de 755 pour les dossiers et 664 au lieu de 644).
Les autorisations de fichier et de dossier de WordPress doivent être les mêmes pour la plupart des utilisateurs et utilisatrices, en fonction du type d’installation que vous avez effectué et des paramètres umask de votre environnement système au moment de l’installation.
NOTE : Si une personne expérimentée a installé WordPress pour vous, vous n’avez probablement pas besoin de modifier les autorisations de fichier. Sauf si vous rencontrez des problèmes avec des erreurs d’autorisation, ou si vous le souhaitez vraiment vous ne devriez probablement pas vous en occuper vous mêmes.
NOTE : Si vous avez installé WordPress vous-même, vous devez probablement modifier les autorisations de fichier.
Certains fichiers et répertoires doivent être « renforcés » avec des autorisations plus strictes, en particulier le fichier wp-config.php.
Ce fichier est initialement créé avec les autorisation en 644, et il est dangereux de le laisser comme ça. Voir Sécuriser WordPress.
En règle générale, tous les fichiers WordPress principaux ne doivent être accessibles en écriture que par votre compte utilisateur (ou le compte httpd, s’il est différent).
Parfois, cependant, plusieurs comptes ftp sont utilisés pour gérer une installation, et si tous les utilisateurs ftp sont connus et approuvés, c’est-à-dire autre qu’un hébergement mutualisé, alors attribuer un groupe accessible en écriture peut être approprié. Demandez à l’administrateur de votre serveur pour plus d’informations.
Cependant, si vous utilisez les permaliens mod_rewrite ou d’autres fonctionnalités .htaccess, vous devez vous assurer que WordPress peut également écrire dans votre fichier /.htaccess.
Si vous souhaitez utiliser l’éditeur de thème natif, tous les fichiers doivent être accessibles en écriture pour le groupe. Essayez de l’utiliser avant de modifier les autorisations des fichiers, cela devrait fonctionner. Cela peut être vrai si différentes personnes ont téléversé le package WordPress et l’extension ou le thème.
Cela ne devrait pas être un problème pour l’extension et les thèmes installés par la personne administrant le site.
Lors du téléversement de fichiers avec différents comptes FTP, un groupe inscriptible est nécessaire. Sur l’hébergement mutualisé, assurez-vous que le groupe est exclusif aux personnes en qui vous avez confiance…
Le compte apache ne doit pas être dans le groupe et ne doit pas posséder de fichiers.
Certaines extensions nécessitent que le dossier /wp-content/ soit accessible en écriture, mais dans ce cas, ils vous en informeront lors de l’installation.
Dans certains cas, cela peut nécessiter l’attribution des permissions 755.
La même chose est vraie pour /wp-content/cache/ et peut-être /wp-content/uploads/
(si vous êtes en installation multisite, vous devrez peut-être également le faire pour /wp-content/blogs.dir/ ).
Les répertoires supplémentaires sous /wp-content/ doivent être documentés par l’extension ou le thème qui les requiert. Les autorisations varieront.
/ |- index.php |- wp-admin | `- wp-admin.css |- wp-blog-header.php |- wp-comments-post.php |- wp-commentsrss2.php |- wp-config.php |- wp-content | |- cache | |- plugins | |- themes | `- uploads |- wp-cron.php |- wp-includes `- xmlrpc.php
Hébergement mutualisé avec suexec
Ce qui précède peut ne pas s’appliquer aux systèmes d’hébergements mutualisés qui utilisent l’approche « suexec » pour exécuter les fichiers binaires PHP. Il s’agit d’une approche populaire utilisée par de nombreux hébergeurs web. Pour ces systèmes, le processus PHP s’exécute en tant que propriétaire des fichiers PHP eux-mêmes, ce qui permet une configuration plus simple et un environnement plus sécurisé pour le cas spécifique de l’hébergement mutualisé.
Note : Les méthodes suexec ne doivent JAMAIS être utilisées sur une configuration de serveur de site unique, c’est plus sûr uniquement dans le cas spécifique de l’hébergement mutualisé.
Dans le cadre d’une configuration suexec, le schéma correct des permissions est simple à comprendre.
- Tous les fichiers doivent être la propriété du compte effectif, et non pas du compte utilisé pour le processus
httpd. - Attribuer la propriété au groupe n’est pas pertinente, sauf lorsqu’il y a des exigences spécifiques pour le groupe du processus du serveur web. Ce n’est habituellement pas le cas.
- Tous les répertoires doivent être en 755 ou en 750.
- Tous les fichiers doivent être en 644 ou en 640. Une exception :
wp‑config.phpqui devrait être en 440 ou 400 pour empêcher d’autres utilisateurs sur le serveur de le lire. - Aucune permission en 777 ne devrait jamais être donnée à un répertoire, même ceux servant au téléchargement. Puisque le processus PHP s’exécute en tant que propriétaire des fichiers, il possède les autorisations des propriétaires et peut écrire, et ce même pour un répertoire en 755.
Dans cette configuration de type spécifique, WordPress détectera qu’il peut directement créer des fichiers avec la propriété appropriée, et ne demandera donc pas d’informations d’identification FTP lors de la mise à niveau ou de l’installation d’extensions.
Les méthodes populaires utilisées par les personnes chargées de l’administration système pour cette configuration sont :
- suPHP, fonctionne via php-cgi, actuellement non maintenu depuis 2013.
- mod_ruid2, module apache, actuellement non maintenu depuis 2013.
- mpm-itk, module apache.
- mod_fcgid, un module Apache et un serveur FastCGI avec une configuration plus étendue.
- PHP-FPM, un serveur FastCGI alternatif avec OPCode partagé, à utiliser avec Apache et Nginx.
Utiliser un Client FTP
Les programmes FTP (« clients ») vous permettent de définir des autorisations pour les fichiers et répertoires sur votre hébergement distant. Cette fonction est souvent appelée chmod ou modifier les permissions dans le menu du programme.
Dans l’installation de WordPress, deux fichiers que vous voudrez probablement modifier sont la page d’index et la feuille de style css qui contrôle la mise en page. Voici comment modifier index.php – le processus est le même pour n’importe quel fichier.
Dans la capture d’écran ci-dessous, regardez la dernière colonne, c’est elle qui montre les persmissions. Cela semble un peu déroutant pour l’instant, notez simplement la séquence de lettres.
Clic droit sur index.php et sélectionnez « Droits d’accès au fichier… »
Une fenêtre apparaîtra alors.
Ne vous inquiétez pas pour les cases à cocher. Il suffit simplement de supprimer la « valeur numérique » et saisissez le nombre dont vous avez besoin – dans notre cas, c’est 666. Puis cliquez sur OK.
Vous pouvez maintenant constater que les permsissions du fichier ont bien été modifiées.
Rendre visibles les fichiers masqués
Par défaut, la plupart des clients FTP, y compris FileZilla, empêchent l’affichage des fichiers cachés, les fichiers commençant par un point (.). Mais, à un moment donné, vous devrez peut-être voir vos fichiers cachés afin de pouvoir modifier les autorisations sur ce fichier. Par exemple, vous devrez peut-être rendre votre fichier .htaccess, le fichier qui contrôle les permaliens, accessible en écriture.
Pour que FileZilla affiche toujours les fichiers cachés : depuis le menu Serveur, cliquez sur Forcer l’affichage des fichiers cachés.
Utiliser la ligne de commande
Si vous avez un accès shell/SSH sur votre compte d’hébergement, vous pouvez utiliser chmod pour modifier les autorisations de fichier, qui est la méthode préférée des utilisateurs expérimentés. Avant de commencer à utiliser chmod, il serait recommandé de lire quelques tutoriels pour vous assurer de comprendre ce que vous pouvez réaliser avec lui.
La définition d’autorisations incorrectes peut mettre votre site hors ligne, veuillez donc prendre votre temps.
Vous pouvez rendre tous les fichiers de votre répertoire wp-content inscriptibles en deux étapes, mais avant de rendre chaque fichier et dossier inscriptibles, vous devriez d’abord essayer des alternatives plus sûres comme modifier uniquement le répertoire. Essayez d’abord chacune de ces commandes et si elles ne fonctionnent pas, alors utilisez le récursif, ce qui rendra même les fichiers images de vos thèmes inscriptibles.
Remplacez DIR par le dossier dans lequel vous souhaitez écrire :
chmod -v 746 DIR chmod -v 747 DIR chmod -v 756 DIR chmod -v 757 DIR chmod -v 764 DIR chmod -v 765 DIR chmod -v 766 DIR chmod -v 767 DIR
Si ceux-ci ne vous permettent pas d’écrire, essayez-les tous à nouveau dans l’ordre, sauf que cette fois-ci remplacez -v par -R, qui modifiera récursivement chaque fichier situé dans le dossier. Si après cela vous ne pouvez toujours pas écrire, vous pouvez maintenant essayer 777.
À propos de Chmod
chmod est une commande UNIX qui signifie «change mode » sur un fichier. Le paramètre -R signifie Récursif et permet d’appliquer les changements sur l’ensemble des fichiers, répertoires et sous-répertoires contenus dans wp-content.
Les permissions 766 sont celles que nous allons appliquer à notre répertoire, ce qui signifie qu’il sera alors accessible en lecture et écriture pour WordPress et pour tous les comptes du système. Enfin, voici le nom du répertoire que nous allons modifier, wp-content. Si 766 ne fonctionne pas, vous pouvez essayer 777, qui rendra tous les fichiers et répertoires accessibles en lecture, écriture et exécution par tous les comptes, groupes et processus.
Si vous utilisez les permaliens vous devez changer en conséquence les permissions du fichier .htaccess pour vous assurer que WordPress peut le mettre à jour lorsque vous modifiez des paramètres comme ajouter une nouvelle page, une redirection, une catégorie, etc., nécessitant la mise à jour du fichier .htaccess lorsque le mod_rewrite est utilisé.
- Allez dans le répertoire principal de WordPress.
- Saisissez
chmod -v 666 .htaccess.
NOTE : D’un point de vue de la sécurité, même une faible protection est préférable à un répertoire accessible en écriture. Commencez avec des réglages plus restrictifs tels que 744, et augmenter les droits jusqu’à ce que cela fonctionne. N’utilisez 777 que si cela est nécessaire, en espérant que ce ne soit que temporaire et pour un temps très court.
Les dangers de 777
Le point crucial de cette question est de savoir comment les permissions sont configurées sur votre serveur. Le compte utilisateur que vous utilisez pour FTP ou SSH sur votre serveur n’est probablement pas le même que celui utilisé par l’application elle-même pour délivrer les pages.
7 7 7
propriétaire groupe autres
r+w+x r+w+x r+w+x
4+2+1 4+2+1 4+2+1 = 777
Souvent, le serveur Apache est « détenu » par les comptes www‑data, dhapache ou nobody. Ces comptes ont des accès limités aux fichiers sur le serveur, pour une très bonne raison. En rendant vos fichiers et dossiers personnels appartenant à votre compte utilisateur accessibles en écriture, vous les rendez littéralement accessible en écriture à tout le monde. Maintenant, les comptes www‑data, dhapache et nobody qui exécutent votre serveur, délivrent les pages, exécutent php, etc., auront un accès complet aux fichiers de votre compte.
Cela permet à n’importe qui d’accéder à vos fichiers en détournant essentiellement n’importe quel processus sur votre serveur, cela inclut également tous les autres comptes utilisant votre machine. Vous devez donc réfléchir attentivement à la modification des autorisations sur votre machine. Il est très rare de rencontrer un cas de figure qui nécessiterait plus de 767, alors quand vous voyez 777, demandez-vous pourquoi cela est nécessaire.
Les conséquences
Le pire qui puisse se produire en raison de l’utilisation de permissions en 777 sur un dossier ou même un fichier, serait qu’un pirate soit capable de téléverser un fichier malicieux ou de modifier un fichier existant pour exécuter du code, il aurait un contrôle complet sur votre site, y compris les informations de votre base de données et le mot de passe.
Trouver une solution de contournement
Il est généralement assez facile d’obtenir des fonctionnalités avancées offertes grâce au nombre important d’extensions WordPress disponibles, sans avoir à se mettre en danger. Contactez l’auteur ou l’autrice de l’extension ou le support de serveur et demandez une solution de contournement.
Trouver des permissions de fichiers sécurisées
Le fichier .htaccess est l’un des fichiers qui est accessible par le propriétaire du processus en cours d’exécution sur le serveur. Donc, si vous définissez des autorisations trop faibles, votre serveur ne sera pas en mesure d’accéder au fichier et générera une erreur. C’est là que réside la méthode pour trouver les réglages les plus sûrs. Démarrez avec des droits trop restrictifs et augmentez les autorisations jusqu’à ce qu’il fonctionne.
Exemples de réglages d’autorisations
L’exemple suivant est un fichier compiled php-cgi binary personnalisé et un php.ini personnalisé situés dans le répertoire cgi-bin pour l’exécution de scripts PHP. Pour empêcher l’interpréteur PHP et le fichier php.ini d’être consulté directement dans un navigateur web, ils sont protégés par un fichier .htaccess.
Permissions par défaut (umask 022) :
644 -rw-r--r-- /home/user/wp-config.php 644 -rw-r--r-- /home/user/cgi-bin/.htaccess 644 -rw-r--r-- /home/user/cgi-bin/php.ini 755 -rwxr-xr-x /home/user/cgi-bin/php.cgi 755 -rwxr-xr-x /home/user/cgi-bin/php5.cgi
Permissions sécurisées :
600 -rw------- /home/user/wp-config.php 604 -rw----r-- /home/user/cgi-bin/.htaccess 600 -rw------- /home/user/cgi-bin/php.ini 711 -rwx--x--x /home/user/cgi-bin/php.cgi 100 ---x------ /home/user/cgi-bin/php5.cgi
Permissions .htaccess
644 > 604 – Le bit autorisant la lecture au groupe propriétaire du fichier .htaccess a été supprimé. 644 est normalement requis et recommandé pour les fichiers .htaccess.
Permissions php.ini
644 > 600 – Auparavant, tous les groupes et tous les comptes ayant accès au serveur pouvaient accéder au fichier php.ini, même simplement en l’appelant à partir du site. La chose la plus délicate, c’est que parce que le fichier php.ini n’est utilisé que par le php.cgi, nous avons seulement besoin de nous assurer que le processus de php.cgi y accède bien. Le php.cgi s’exécute en tant que compte possédant les deux fichiers, de sorte que le compte unique est désormais le seul compte pouvant accéder à ce fichier.
Permissions php.cgi
755 > 711 – Ce fichier est une compilation php-cgi binaire utilisé à la place de mod_php ou le PHP natif fourni par défaut par la société d’hébergement. Les autorisations par défaut pour ce fichier sont 755.
Permissions php5.cgi
755 > 100 – En raison de la configuration où le compte utilisateur est le propriétaire du processus exécutant le cgi php, aucun autre compte ou groupe n’a besoin d’y accéder, donc nous avons désactivé tous les accès hors accès en exécution. C’est intéressant parce que ça fonctionne vraiment.
Vous pouvez essayer de lire le fichier, écrire dans le fichier, etc. mais le seul accès que vous avez à ce fichier est d’exécuter des scripts PHP. Et en tant que propriétaire du fichier, vous pouvez toujours changer les permissions à nouveau.
$ cat: php5.cgi: Permission denied ./php5.cgi: Welcome
SELinux
Security Enhanced Linux est un module de sécurité du noyau Linux qui fournit des mécanismes par lesquels les processus peuvent être mis en bac à sable dans des contextes particuliers. Ceci est particulièrement utile pour limiter les actions que les pages web peuvent effectuer sur d’autres parties du système d’exploitation. Les actions refusées par la stratégie de sécurité sont souvent difficiles à distinguer des erreurs d’autorisation de fichier normales.
SELinux est généralement installé sur les distributions de la famille Redhat (par exemple, CentOS, Fedora, Scientific, Amazon et autres).
Comment déterminer si SELinux est le problème ?
Si vous utilisez une distribution basée sur Debian, tout va probablement se passer assez simplement.
Exécutez la commande suivante (sur les systèmes basés sur rpm) :
# rpm -qa | grep selinux selinux-policy-targeted-3.13.1-166.el7_4.7.noarch selinux-policy-3.13.1-166.el7_4.7.noarch libselinux-2.5-11.el7.x86_64 libselinux-python-2.5-11.el7.x86_64 libselinux-utils-2.5-11.el7.x86_64
et pour vérifier si la cause est un refus d’autorisations :
# getenforce Enforcing
Un problème causé par SELinux est d’empêcher les outils wp-admin d’écrire dans le fichier .htaccess requis pour la réécriture d’url.
Il existe plusieurs commandes pour inspecter ce comportement :
# audit2allow -w -a type=AVC msg=audit(1517275570.388:55362): avc: denied { write } for pid=11831 comm="httpd" path="/var/www/example.org/.htaccess" dev="vda1" ino=67137959 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file Was caused by: The boolean httpd_unified was set incorrectly. Description: Allow httpd to unified Allow access by executing: # setsebool -P httpd_unified 1
et
# ausearch -m avc -c httpd ---- time->Tue Jan 30 01:30:31 2018 type=PROCTITLE msg=audit(1517275831.762:55364): proctitle=2F7573722F7362696E2F6874747064002D44464F524547524F554E44 type=SYSCALL msg=audit(1517275831.762:55364): arch=c000003e syscall=21 success=no exit=-13 a0=55b9c795d268 a1=2 a2=0 a3=1 items=0 ppid=11826 pid=11829 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1517275831.762:55364): avc: denied { write } for pid=11829 comm="httpd" name="bioactivator.org" dev="vda1" ino=67137958 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=dir ----
Vous pouvez désactiver temporairement SELinux pour déterminer s’il est la cause des problèmes :
# setenforce usage: setenforce [ Enforcing | Permissive | 1 | 0 ]
Voir aussi
- Fil de discussion du forum d’assistance (en anglais)
- htaccess pour les sous-dossiers (en anglais)
- Modifier les autorisations par défaut des fichiers
Traduit par Patrice Pichon
Relu par Jb Audras & Jenny Dupuy
D’après la version anglaise du 24 février 2019
Dernière mise à jour le 04 mai 2021
Contribuer à la documentation en français de WordPress
Journal des modifications
04 mai 2021 – Jenny Dupuy – Suppression de l’encodage des caractères accentués ou spéciaux dans les liens concernés