Réduire les permissions excessives des fichiers WordPress sur une copie locale

Identifier l’écriture nécessaire sur une copie locale

Dans une copie locale fictive, l’import d’un fichier de démonstration a fini par fonctionner après un élargissement des permissions. Pour savoir quelles écritures sont vraiment nécessaires, relevez le propriétaire, le groupe ou les entrées d’accès, puis réduisez le droit en trop sur un seul objet. Rejouez la même action avec les identités de démonstration prévues.

Commencez par isoler la copie. Donnez-lui un dossier, une adresse locale et une base distincts. Chargez un jeu de contenus et de comptes fictifs, puis neutralisez les courriels, les paiements, les tâches et les intégrations sortantes. Vérifiez que les chemins de la copie ne pointent pas vers les fichiers du site réel. Une copie posée sur NTFS ou sur un montage de conteneur ne reproduit pas forcément les règles d’un hébergement Linux.

Les rôles du tableau de bord contrôlent des actions dans WordPress. Les permissions de fichiers régissent les accès des utilisateurs et des processus du système. Si le refus concerne une fonction du tableau de bord après connexion, commencez par vérifier les capacités du compte WordPress.

Relever la portée du changement avant toute correction

Retrouvez ce qui a été modifié : un fichier, un dossier, tous ses descendants ou toute l’installation. Notez la commande ou l’action de panneau utilisée, si elle est connue, sans la relancer. Conservez la date, le domaine et les valeurs observées. Une case de récursivité peut avoir touché beaucoup plus que l’élément visible.

Relevez la version de WordPress, le panneau et le type d’exécution PHP avec le responsable technique. Repérez une sauvegarde qui conserve les données utiles, mais ne supposez pas qu’une archive restitue forcément tous les propriétaires et permissions d’origine. Demandez ce que l’outil préserve réellement.

Gardez un accès fiable au compte d’hébergement pendant l’intervention. Si le site ne peut plus lire sa configuration après une restriction, cet accès doit permettre une correction ciblée. Pour l’exercice, relevez l’état du seul fichier témoin et conservez la possibilité de le restaurer dans la copie.

Comprendre les trois informations qui déterminent l’accès

Sur un système de fichiers Linux courant, un objet possède un propriétaire, un groupe et des permissions. Les catégories propriétaire, groupe et autres ne désignent pas les rôles Administrateur, Éditeur et Auteur de WordPress. Elles concernent les comptes et processus du serveur.

Les permissions distinguent lecture, écriture et exécution. Pour un dossier, le droit de parcours permet d’accéder aux objets dont on connaît le nom. Une restriction du dossier parent peut donc bloquer un fichier dont les droits semblent corrects.

Il faut aussi savoir sous quelle identité l’opération échoue. Le compte SFTP, le serveur web et PHP ne sont pas toujours le même utilisateur. PHP-FPM, lorsqu’il est utilisé, possède un utilisateur et un groupe d’exécution configurés. Le bon réglage dépend de l’identité configurée pour la tâche.

Faire le relevé avant de modifier le témoin

1. Dans la copie, choisissez un fichier factice temoin.txt et notez son chemin, le volume, le propriétaire, le groupe et les autorisations. Relevez aussi les règles du dossier parent. Dans un environnement Linux, vérifiez si une ACL existe et gardez le relevé des entrées et du masque. Retenez un fichier ordinaire de la copie, sans lien symbolique. Gardez un relevé avant modification pour rétablir l’état exact de l’exercice.
2. Donnez un nom aux identités de l’essai. Dans l’exemple, atelier-app est le propriétaire fictif et écrit le témoin. Un compte de lecture distinct, sans privilège d’administration, a besoin de lire le témoin mais d’aucune écriture. Le compte qui a ouvert le terminal peut être différent du processus applicatif. Sur l’hébergement réel, le fournisseur doit confirmer ces identités et la politique attendue avant toute transposition.
3. Classez l’écart. Si le propriétaire attendu correspond et qu’un droit supplémentaire est clairement identifié, corrigez ce droit sur le témoin. Si le propriétaire est différent, si une ACL ou un héritage manque au relevé ou si le volume est géré, demandez une vérification ciblée avant de changer le mode. Si le problème initial est un refus d’installation, consultez le diagnostic du dossier d’installation.

Sous Linux, lire le mode et le propriétaire du témoin

Sur une copie locale sous Linux avec les outils GNU, placez-vous dans le dossier isolé du test. Dans cet exemple, le fichier fictif a le mode 664, le groupe a un droit d’écriture superflu et aucune ACL étendue ne s’applique. Le propriétaire fictif est bien l’identité qui doit écrire. Lancez d’abord le relevé seul. La modification n’est indiquée que si le nom, le type, le propriétaire et le groupe concordent avec le relevé de l’exercice.

stat -c '%A %a %U:%G %n' -- ./temoin.txt

Sous Linux, retirer l’écriture superflue sur le témoin

Dans ce scénario, retirez l’écriture au groupe et aux autres sur ce fichier précis, puis reprenez la même mesure.

chmod go-w -- ./temoin.txt
stat -c '%A %a %U:%G %n' -- ./temoin.txt

Interpréter le résultat du témoin Linux

Le relevé doit passer de 664 à 644, avec le même propriétaire et le même groupe. Le propriétaire conserve son écriture et le groupe sa lecture. Ce résultat dépend du besoin annoncé dans l’exercice. Si le processus PHP écrit par l’intermédiaire du groupe, retirer ce droit peut bloquer la fonction. Si une ACL est présente, faites contrôler son masque et les droits effectifs des entrées avant de réutiliser cette démarche.

Refaites ensuite la lecture et l’écriture depuis les comptes de démonstration prévus. L’écriture par le propriétaire doit réussir et l’écriture par le compte de lecture doit échouer. Vérifiez que les répertoires parents restent traversables par les identités requises. Contrôlez aussi l’écriture sur le dossier parent. Sur un dossier ordinaire, elle peut permettre le remplacement ou la suppression d’un fichier même si l’écriture directe dans ce fichier est refusée. Si le témoin devait être privé en lecture, le mode de cet exercice ne correspondrait pas au besoin. En cas d’échec, revenez au relevé initial de la copie et corrigez le modèle avant une nouvelle tentative.

Sous Windows, réduire une entrée d’accès explicite

Sur une copie NTFS, ouvrez Propriétés → Sécurité → Avancé sur le fichier témoin. Relevez le propriétaire et l’origine des entrées, explicites ou héritées. Pour une lecture complémentaire depuis PowerShell, placez-vous dans le dossier de l’exercice et utilisez la commande suivante sur le fichier fictif.

Si la ligne excessive appartient explicitement au compte de démonstration et lui est propre, sélectionnez cette seule entrée. Retirez le droit de modification ou remplacez-le par la lecture selon le besoin prévu. Si l’entrée est héritée, identifiez le parent et demandez au responsable de confirmer à quel niveau la règle doit changer. Contrôlez ensuite la lecture autorisée et l’écriture refusée avec les identités fictives, ainsi que l’écriture qui doit rester autorisée. En cas d’échec, rétablissez uniquement l’entrée documentée du témoin, ou recréez le témoin depuis la base de l’exercice.

Sur un hébergement Windows géré, faites confirmer le compte d’exécution et les règles héritées au support. Sur un hébergement Linux mutualisé, le prestataire peut imposer un propriétaire ou un groupe selon l’isolation des sites. Sur un serveur administré, identifiez le compte réel du service et le volume en jeu. Une différence entre ces environnements limite la portée de la conclusion locale.

Sur un fichier témoin NTFS, nous avons remplacé l’autorisation explicite de modification par la lecture pour un identifiant fictif. Le propriétaire, les autres entrées et l’héritage sont restés identiques. Le créateur a pu lire et écrire, puis la liste des autorisations a retrouvé exactement son état d’avant la correction. Une session avec un deuxième compte reste nécessaire pour vérifier les droits effectifs de cette identité sur votre propre copie.

Get-Acl -LiteralPath '.\temoin.txt' | Format-List Owner, AccessToString

Vérifier les possibilités du panneau d’hébergement

Dans cPanel, ouvrez File Manager, sélectionnez le fichier ou dossier concerné, puis Permissions. Les cases ou la valeur numérique permettent de préparer le mode confirmé. Vérifiez la sélection avant Change Permissions. Ne conservez pas une valeur proposée par défaut uniquement parce qu’elle est déjà affichée.

Dans Plesk pour Linux, le parcours est Websites & Domains, le domaine, puis File Manager. Sélectionnez l’élément et Change Permissions. Gardez la case de modification récursive désactivée pour cet essai ciblé, puis enregistrez. Si le bouton manque pour un fichier appartenant à un autre utilisateur du système, faites intervenir l’hébergeur.

Si votre copie possède le même panneau, rouvrez la fiche de son fichier témoin et effectuez l’essai fictif prévu. Si la valeur n’a pas changé ou si une nouvelle erreur apparaît, consignez le message et demandez une correction ciblée. Maintenez la restriction adaptée pendant le diagnostic.

Approche 2 : faire corriger le propriétaire ou le groupe

Après une restauration, les fichiers peuvent appartenir à un compte différent de celui qui exécute le site. La personne connectée par SFTP peut réussir une écriture alors que PHP échoue, ou l’inverse. Donnez au support le chemin précis et les résultats de ces deux contextes lorsqu’ils sont connus.

Demandez quel utilisateur doit posséder les fichiers, quel groupe est prévu et quelle identité réalise l’action WordPress. Sur PHP-FPM, le pool du site possède ses paramètres d’utilisateur et de groupe. Le mainteneur confirme l’identité dans la configuration effective du site.

Une correction de propriétaire doit rester limitée au périmètre validé. Ne demandez pas de faire appartenir tout l’hébergement au serveur web, ni de partager un propriétaire unique entre sites sans raison. Après intervention dans la copie, relevez les nouvelles valeurs et reprenez le même essai fictif. Si l’erreur persiste dans la copie, faites vérifier les autres restrictions.

Approche 3 : reconstruire une politique après un changement récursif

Si une action a touché toute l’arborescence, demandez un inventaire avant une remise en ordre collective. Séparez fichiers du programme, répertoires de médias, caches, éléments de configuration, outils de déploiement et contenus privés. Ils ne doivent pas recevoir mécaniquement le même mode.

Le responsable prépare une politique par famille, adaptée au propriétaire, au groupe et aux besoins d’écriture de cet hébergement. Les exceptions doivent être identifiées, notamment les répertoires créés par une extension ou un service. Un autre site qui fonctionne sur le même serveur ne constitue pas nécessairement un modèle identique.

L’application peut être progressive : corriger une famille, vérifier sa lecture et ses écritures utiles, puis poursuivre. Conservez le relevé préalable et la possibilité d’annuler une étape précise. Une opération récursive peut aussi toucher des dossiers partagés ou des cibles de liens symboliques. Faites confirmer ces limites avant toute opération globale par le prestataire.

Lire les valeurs sans les transformer en recette universelle

Dans la notation courante à trois chiffres, chaque position correspond au propriétaire, au groupe puis aux autres utilisateurs du système. Les valeurs combinent les droits de lecture, d’écriture et de parcours ou d’exécution. Le mode 777 ouvre les trois droits aux trois catégories. Le mode 666 ouvre notamment l’écriture d’un fichier à tous.

Les chiffres ne disent pas qui est le propriétaire ni quels groupes possède le processus. Ainsi, un dossier qui n’est pas ouvert à tous peut rester inscriptible par PHP si PHP agit sous l’identité autorisée. Inversement, un mode courant ne répare pas une identité incorrecte.

Le terme « autres » ne signifie pas simplement visiteurs anonymes du navigateur. Un fichier peut être lu par le serveur puis diffusé sur Internet selon sa configuration. Pour un document confidentiel, la protection doit aussi considérer l’accès HTTP. Si un panneau montre des droits spéciaux ou des entrées supplémentaires, demandez au responsable de les interpréter.

Préserver les règles particulières de l’hébergement

Certaines racines de domaines ont une politique d’accès spécifique. Par exemple, cPanel EasyApache peut utiliser FileProtect pour restreindre leur lecture aux identités prévues. Une racine qui n’affiche pas le mode courant attendu par un tutoriel n’est donc pas nécessairement mal configurée.

Demandez au prestataire si une telle protection est active avant de toucher au dossier parent du site. Ne désactivez pas un mécanisme d’isolation pour appliquer partout une valeur familière. Il peut protéger plusieurs domaines et relever de l’administration du serveur.

Le même principe vaut pour les fichiers privés, notamment la configuration contenant les accès de base de données. Ils doivent rester lisibles par les services nécessaires, sans être ouverts à d’autres utilisateurs sans raison. Une valeur restrictive choisie sans connaître l’identité de lecture peut provoquer une panne. Faites confirmer la politique et le chemin réel de la configuration.

Examiner les ACL et l’héritage avant de supprimer des exceptions

Les ACL sont des listes d’accès qui peuvent ajouter des autorisations nominatives au modèle propriétaire, groupe et autres. Un dossier peut aussi transmettre des droits aux objets créés ensuite. Les trois chiffres affichés ne suffisent donc pas toujours à décrire toute la politique.

Faites relever ces règles par le responsable avant une remise en ordre. Retirer une entrée ou modifier un mode peut changer des droits effectifs au-delà de ce qui paraît visible dans un panneau simplifié. Ne supprimez pas toutes les ACL pour remettre une apparence « propre ».

Sur Windows, les autorisations et leur héritage utilisent un autre modèle. Dans Plesk, l’écran peut afficher des utilisateurs, des groupes et des cases Autoriser ou Refuser plutôt qu’un mode Linux. Ne convertissez pas ces règles en 644 ou 755. Faites examiner la règle héritée et le compte de service concerné, en conservant les entrées nécessaires à l’hébergement.

Contrôler les objets nouvellement créés et les restrictions restantes

Après correction d’un dossier de médias ou de cache, examinez un nouvel objet créé par le mécanisme normal. Le mode d’un fichier existant et celui d’un futur fichier ne sont pas nécessairement identiques. Le masque de création, appelé umask, et les règles héritées peuvent influencer les nouvelles permissions.

Si chaque nouvel envoi recrée des droits trop ouverts, ne corrigez pas les fichiers manuellement après chaque usage. Faites examiner l’outil de transfert, le traitement ou la configuration qui les crée. Demandez une règle adaptée à ce service, sans modifier le masque de tout le serveur pour un seul site.

Si une écriture reste refusée malgré les droits attendus, faites vérifier aussi les restrictions du système ou un volume en lecture seule. Élargir encore les permissions ne peut pas lever toutes ces restrictions. Transmettez le message exact et le chemin concerné au prestataire en laissant les protections actives.

Adapter la correction à WordPress.com et au multisite

Sur WordPress.com, certains fichiers et dossiers sont gérés par la plateforme et ne peuvent pas être modifiés librement. Des composants peuvent être partagés au moyen de liens symboliques. Pour ces zones, faites vérifier la politique d’accès par la plateforme.

Adressez au support le chemin, le changement appliqué et la fonction concernée. Les accès aux fichiers disponibles dépendent de votre environnement. Pour une zone gérée, appliquez la procédure du prestataire. Un refus dans le tableau de bord peut aussi relever des capacités du compte, distinctes des permissions du disque.

Dans un réseau multisite, confirmez si le dossier est propre à un sous-site ou partagé. Le responsable du réseau doit valider une modification qui affecte les fichiers communs. Un administrateur local ne doit pas faire ouvrir toute l’installation pour permettre l’envoi d’un média sur son seul site. Le contrôle doit couvrir la fonction concernée et les sites potentiellement affectés.

Contrôler l’écriture attendue et le refus prévu

1. Rejouez dans la copie l’opération qui justifiait l’écriture. Par exemple, faites téléverser une petite image de démonstration par un compte WordPress fictif autorisé. Contrôlez que l’interface confirme le résultat et que le fichier créé existe avec les droits attendus. Pour vérifier une écriture de fichier, privilégiez le trajet qui écrit réellement sur le disque. Un brouillon enregistré en base peut réussir pendant que le dépôt de médias échoue.
2. Rejouez un contrôle négatif dans la même copie. L’identité de lecture fictive doit pouvoir lire son témoin et se voir refuser une modification. Vérifiez que le fichier de programme choisi comme témoin reste en lecture seule pour le processus applicatif si la politique locale le prévoit. Comparez les droits et l’identité du fichier créé par l’application au relevé, car les règles de création et d’héritage peuvent différer des droits des fichiers présents.
3. Arrêtez l’exercice si un objet inattendu change ou si une fonction autorisée cesse de marcher. Comparez le résultat avec l’état initial, restaurez la dernière modification ciblée sur la copie et vérifiez l’identité qui exécute l’action. Pour un échec de dépôt, le guide WordPress sur le refus d’écriture sur le disque aide à distinguer le répertoire temporaire, la capacité de stockage et la destination.
4. Notez les conditions de réussite et leurs limites. Remettez au responsable le chemin relatif, l’identité d’écriture attendue, la règle avant et après, les essais positifs et négatifs et le retour arrière testé ou prévu. Pour un environnement géré, demandez au prestataire de confirmer la règle équivalente et le périmètre exact. La réussite du test local permet de formuler la demande avec précision.

Évaluer la période passée et éviter une nouvelle ouverture générale

Notez depuis quand les droits trop larges étaient appliqués et sur quel périmètre. Cela ne prouve pas qu’une intrusion a eu lieu. Le propriétaire ou l’hébergeur peut toutefois devoir examiner les modifications de fichiers et les accès sur cette période, surtout si d’autres anomalies apparaissent.

Des fichiers inconnus, des administrateurs non reconnus ou une redirection inattendue demandent une investigation distincte. Réduire les permissions ne retire pas automatiquement un contenu malveillant déjà présent. Préservez les traces et faites coordonner les mesures nécessaires par le responsable sécurité.

Conservez enfin la cause établie, les modes et identités attendus, les exceptions et les contrôles effectués. Faites documenter le réglage des prochains déploiements ou transferts. La prévention consiste à corriger le mécanisme qui a nécessité l’ouverture, avec un interlocuteur identifié, plutôt qu’à garder une commande globale de permissions comme solution habituelle à chaque erreur.