Permissions de fichiers PrestaShop : La configuration correcte

Comprendre les permissions de fichiers Linux

Chaque fichier et répertoire sur un serveur Linux possède trois ensembles de permissions : un pour le propriétaire, un pour le groupe, et un pour les autres (tous les autres utilisateurs). Chaque ensemble contrôle trois actions : lecture (r), écriture (w), et exécution (x). Ces permissions sont représentées numériquement en notation octale, où la lecture vaut 4, l'écriture vaut 2 et l'exécution vaut 1. Les valeurs sont additionnées pour chaque ensemble, produisant un nombre à trois chiffres comme 755 ou 644.

Par exemple, une permission de 755 signifie que le propriétaire peut lire, écrire et exécuter (7 = 4+2+1), tandis que le groupe et les autres ne peuvent que lire et exécuter (5 = 4+0+1). Une permission de 644 signifie que le propriétaire peut lire et écrire (6 = 4+2+0), tandis que le groupe et les autres ne peuvent que lire (4 = 4+0+0). Comprendre ce système est fondamental pour gérer une boutique PrestaShop sécurisée et fonctionnelle.

Au-delà des permissions numériques, chaque fichier a un propriétaire et un groupe qui lui sont associés. Sur un serveur web, le processus du serveur web (Apache ou Nginx) s'exécute sous un utilisateur spécifique, généralement www-data sur Debian/Ubuntu ou apache/nobody sur CentOS/RHEL. Le serveur web a besoin de lire vos fichiers PrestaShop pour les servir, et il a besoin d'un accès en écriture à certains répertoires pour les téléchargements, la mise en cache et la configuration.

Permissions correctes pour les répertoires et fichiers PrestaShop

La règle générale pour PrestaShop est simple : les répertoires doivent être en 755 et les fichiers en 644. Cela donne au propriétaire un contrôle total, tandis que le groupe et les autres peuvent lire (et exécuter/traverser dans le cas des répertoires) mais ne peuvent rien modifier. L'utilisateur du serveur web doit être le propriétaire de tous les fichiers PrestaShop, ou au minimum appartenir au groupe qui les possède.

Pour définir ces permissions sur l'ensemble de votre installation PrestaShop, connectez-vous à votre serveur via SSH et exécutez :

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;

Remplacez /var/www/html/prestashop par le chemin réel de votre installation PrestaShop. La première commande trouve tous les répertoires et les met en 755. La seconde trouve tous les fichiers et les met en 644.

Cependant, certains répertoires nécessitent un accès en écriture par le serveur web. Ces répertoires demandent une attention particulière car PrestaShop y écrit pendant son fonctionnement normal :

• /var/cache/ — Templates Smarty compilés et cache Symfony
• /var/logs/ — Fichiers de journalisation de l'application
• /upload/ — Fichiers téléchargés par les clients
• /download/ — Fichiers de produits virtuels
• /img/ — Images produits, images de catégories, images CMS
• /modules/ — Installation et mises à jour des modules
• /themes/ — Fichiers de cache du thème
• /translations/ — Fichiers d'export de traductions
• /config/ — Fichiers de configuration (parameters.php)
• /app/config/ — Configuration Symfony
• /app/Resources/translations/ — Traductions Symfony

Si l'utilisateur du serveur web est le propriétaire de ces fichiers (ce qui est la configuration recommandée), alors les permissions 755/644 sont suffisantes. Si le serveur web s'exécute sous un utilisateur différent, vous devrez peut-être ajuster les permissions de groupe ou la propriété.

Définir la bonne propriété avec chown

La propriété est tout aussi importante que les permissions. La commande chown modifie le propriétaire et le groupe des fichiers. Pour un serveur Debian/Ubuntu typique exécutant Apache ou Nginx, l'utilisateur du serveur web est www-data :

sudo chown -R www-data:www-data /var/www/html/prestashop

Le flag -R applique le changement récursivement à tous les fichiers et sous-répertoires. Sur les systèmes CentOS ou RHEL, remplacez www-data par apache ou nginx selon votre serveur web.

Une approche alternative courante consiste à définir le propriétaire comme votre utilisateur SSH/FTP et le groupe comme l'utilisateur du serveur web. Cela vous permet de modifier les fichiers via FTP ou SSH tout en permettant au serveur web de les lire :

sudo chown -R votreutilisateur:www-data /var/www/html/prestashop

Dans ce cas, les répertoires nécessitant un accès en écriture par le serveur web doivent être mis en 775 (écriture de groupe) et les fichiers accessibles en écriture en 664 :

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/var -type f -exec chmod 664 {} \;
find /var/www/html/prestashop/img -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/img -type f -exec chmod 664 {} \;

Hébergement mutualisé vs VPS vs Serveur dédié

L'environnement d'hébergement affecte considérablement le fonctionnement des permissions de fichiers en pratique. Comprendre les différences est essentiel pour configurer correctement les permissions.

Hébergement mutualisé

Sur un hébergement mutualisé, vous accédez généralement aux fichiers via FTP ou un gestionnaire de fichiers dans cPanel/Plesk. Le modèle d'exécution PHP varie selon l'hébergeur, mais la plupart des hébergeurs mutualisés modernes utilisent PHP-FPM ou suPHP, ce qui signifie que PHP s'exécute sous votre compte utilisateur plutôt que sous l'utilisateur global du serveur web. Cela simplifie considérablement les permissions : puisque PHP s'exécute sous votre utilisateur, il peut déjà lire et écrire dans vos fichiers avec les permissions standard 755/644. Vous avez rarement besoin de changer la propriété sur un hébergement mutualisé car tout appartient déjà à votre compte.

Si vous rencontrez des erreurs de permissions sur un hébergement mutualisé, vérifiez auprès de votre hébergeur s'il utilise suPHP ou PHP-FPM. S'il utilise l'ancien modèle mod_php, vous devrez peut-être mettre temporairement certains répertoires en 777 (bien que cela ne soit pas recommandé pour des raisons de sécurité). La plupart des hébergeurs réputés ont abandonné mod_php précisément en raison de ces complications de permissions.

VPS (Serveur Privé Virtuel)

Sur un VPS, vous avez un contrôle total. C'est la configuration la plus courante pour les boutiques PrestaShop sérieuses. Vous devez vous assurer que l'utilisateur du serveur web possède les fichiers PrestaShop ou, au minimum, appartient à un groupe ayant un accès en lecture. La configuration recommandée est :

1. Définir le propriétaire en www-data:www-data (ou votre utilisateur de serveur web)
2. Utiliser 755 pour les répertoires et 644 pour les fichiers
3. Utiliser SSH avec sudo pour effectuer des modifications, ou ajouter votre utilisateur SSH au groupe www-data

Pour ajouter votre utilisateur SSH au groupe du serveur web :

sudo usermod -a -G www-data votreutilisateur

Puis définissez le bit d'écriture de groupe sur les répertoires que vous devez modifier :

chmod g+w /var/www/html/prestashop/themes/votre-theme/

Serveur dédié

Les serveurs dédiés suivent les mêmes principes que les configurations VPS. La principale différence est la performance : vous disposez de plus de ressources, ce qui vous permet d'exécuter PHP-FPM avec des pools dédiés par site. Chaque pool peut s'exécuter sous un utilisateur différent, offrant une meilleure isolation si vous hébergez plusieurs boutiques PrestaShop sur le même serveur.

Modèles d'exécution PHP : suPHP vs mod_php vs PHP-FPM

La manière dont PHP est exécuté sur votre serveur détermine directement quel utilisateur écrit les fichiers et donc quelles permissions sont nécessaires.

mod_php (module Apache)

C'est le modèle le plus ancien et le plus simple. PHP s'exécute comme partie intégrante du processus Apache, ce qui signifie que tout le code PHP s'exécute sous l'utilisateur Apache (généralement www-data ou apache). Le problème est que les fichiers créés par PHP (cache, téléchargements, etc.) appartiennent à l'utilisateur du serveur web, pas à votre compte. Cela peut rendre la gestion FTP difficile et crée des préoccupations de sécurité sur les hébergements mutualisés car tous les sites s'exécutent sous le même utilisateur.

Avec mod_php, les fichiers PrestaShop doivent appartenir à l'utilisateur Apache, et les permissions 755/644 fonctionnent correctement. Cependant, ce modèle est largement obsolète sur les serveurs modernes.

suPHP

suPHP exécute PHP en tant que propriétaire du fichier plutôt qu'en tant qu'utilisateur du serveur web. Cela signifie que si vos fichiers appartiennent à votreutilisateur, PHP s'exécute également sous votreutilisateur. C'est plus sécurisé sur l'hébergement mutualisé car chaque compte est isolé. Les permissions standard 755/644 fonctionnent parfaitement avec suPHP car le processus PHP et le propriétaire du fichier sont le même utilisateur.

Un point important à noter : suPHP rejette en fait les fichiers avec des permissions 777 ou les fichiers appartenant à d'autres utilisateurs. Si vous mettez 777 sur un serveur suPHP, PHP refusera d'exécuter ces fichiers, affichant à la place une erreur 500 Internal Server Error.

PHP-FPM (FastCGI Process Manager)

PHP-FPM est le standard moderne. Il exécute PHP comme un processus séparé du serveur web, avec un utilisateur/groupe configurable par pool. Sur un VPS, PHP-FPM s'exécute généralement sous www-data. Sur un hébergement mutualisé avec CloudLinux ou similaire, chaque compte obtient son propre pool PHP-FPM s'exécutant sous l'utilisateur de ce compte.

PHP-FPM combiné avec Nginx est la configuration recommandée pour les performances PrestaShop. Le schéma de permissions standard 755/644 fonctionne bien. Assurez-vous que l'utilisateur du pool PHP-FPM correspond au propriétaire des fichiers ou dispose d'un accès de groupe approprié.

Pourquoi les permissions 777 sont dangereuses

Mettre les permissions à 777 signifie que n'importe qui sur le système peut lire, écrire et exécuter le fichier. Sur un hébergement mutualisé, cela signifie que d'autres comptes sur le même serveur pourraient potentiellement lire vos identifiants de base de données depuis parameters.php ou injecter du code malveillant dans vos fichiers PHP.

Même sur un VPS où vous êtes le seul utilisateur, 777 est inutile et indique une mauvaise configuration. Si le serveur web ne peut pas écrire dans un répertoire avec les permissions 755, la solution est de corriger la propriété, pas d'ouvrir les permissions au monde entier. Voici ce que vous devriez faire au lieu d'utiliser 777 :

1. Vérifiez sous quel utilisateur le serveur web s'exécute : ps aux | grep -E "apache|nginx|httpd"
2. Vérifiez la propriété des fichiers : ls -la /var/www/html/prestashop/
3. Corrigez la propriété : sudo chown -R www-data:www-data /chemin/vers/repertoire
4. Définissez les permissions correctes : chmod 755 /chemin/vers/repertoire

Si vous trouvez un tutoriel ou un message de forum recommandant 777 pour PrestaShop, c'est un conseil obsolète et dangereux. Le seul usage légitime de 777 est pour les répertoires /tmp qui ont le sticky bit activé (affiché comme 1777), ce qui est une configuration au niveau système, pas quelque chose que vous appliquez aux fichiers PrestaShop.

Considérations Docker pour PrestaShop

Exécuter PrestaShop dans Docker introduit une complexité supplémentaire pour les permissions de fichiers. À l'intérieur du conteneur, le serveur web s'exécute sous www-data avec un UID spécifique (souvent 33 sur les images basées sur Debian). Sur le système hôte, votre utilisateur a un UID différent. Lorsque vous utilisez des montages bind Docker pour monter vos fichiers PrestaShop dans le conteneur, la propriété des fichiers est déterminée par l'UID numérique, pas par le nom d'utilisateur.

Cela signifie que les fichiers créés sur l'hôte sous votre utilisateur (par ex., UID 1000) apparaîtront à l'intérieur du conteneur comme UID 1000, qui n'est pas www-data (UID 33). Le serveur web à l'intérieur du conteneur pourrait ne pas être en mesure d'écrire dans ces fichiers.

Les solutions pour les problèmes de permissions Docker incluent :

• Faire correspondre les UIDs : Créez un utilisateur à l'intérieur du conteneur avec le même UID que votre utilisateur hôte, ou changez le serveur web pour qu'il s'exécute sous votre UID.
• Utiliser chown dans l'entrypoint : Ajoutez une commande de démarrage qui exécute chown -R www-data:www-data /var/www/html au démarrage du conteneur. C'est simple mais peut être lent pour les installations volumineuses.
• Définir les permissions de groupe : Ajoutez votre utilisateur hôte et www-data au même groupe (par GID), puis utilisez les permissions 775/664.
• Volumes nommés : Utilisez des volumes nommés Docker au lieu des montages bind. Docker gère les permissions automatiquement, mais vous perdez l'accès direct au système de fichiers depuis l'hôte.

Pour les environnements de développement avec des montages bind, l'approche la plus pratique est d'exécuter une commande chown après la synchronisation ou le déploiement des fichiers :

docker exec votre-conteneur chown -R www-data:www-data /var/www/html/modules/votre-module/

Soyez conscient que les opérations à l'intérieur du conteneur (comme l'installation d'un module) peuvent créer des fichiers sous www-data, tandis que les opérations sur l'hôte créent des fichiers sous votre utilisateur hôte. Cette inadéquation constante d'UID est la source la plus courante de problèmes de permissions dans les configurations PrestaShop dockerisées.

Dépannage des erreurs de permissions courantes

"Failed to open stream: Permission denied"

Cette erreur signifie que PHP ne peut pas lire ou écrire dans un fichier. Vérifiez la propriété et les permissions du fichier mentionné dans l'erreur. La cause la plus courante est que l'utilisateur du serveur web ne possède pas le fichier ou le répertoire. Corrigez cela avec :

sudo chown www-data:www-data /chemin/vers/fichier
sudo chmod 644 /chemin/vers/fichier

"Unable to write to cache directory"

Le moteur de templates Smarty et le framework Symfony de PrestaShop écrivent tous deux des fichiers de cache. Si le répertoire var/cache/ n'est pas accessible en écriture, vous verrez cette erreur. Le répertoire de cache doit appartenir à l'utilisateur du serveur web :

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/
sudo chmod -R 755 /var/www/html/prestashop/var/cache/

Après avoir corrigé les permissions, videz le cache existant en supprimant le contenu des répertoires de cache :

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*
sudo rm -rf /var/www/html/prestashop/var/cache/dev/*

"Cannot upload image" ou "Cannot install module"

Les téléchargements d'images vont dans le répertoire img/, et les installations de modules écrivent dans le répertoire modules/. Les deux doivent être accessibles en écriture par l'utilisateur du serveur web. De plus, vérifiez que les paramètres PHP upload_max_filesize et post_max_size sont suffisamment grands pour vos fichiers, car ils peuvent produire des erreurs au libellé similaire.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/
sudo chown -R www-data:www-data /var/www/html/prestashop/modules/

"index.php is not writable" pendant les mises à jour

L'outil de mise à jour automatique de PrestaShop a besoin d'un accès en écriture à quasiment tous les fichiers de l'installation. Avant de lancer une mise à jour, définissez la propriété de l'ensemble de l'installation pour l'utilisateur du serveur web. Une fois la mise à jour terminée, vous pouvez restaurer une propriété plus restrictive si vous le souhaitez.

Page blanche après modification des permissions

Si vous voyez une page blanche après avoir modifié les permissions, vous avez peut-être accidentellement supprimé la permission d'exécution des répertoires. Les répertoires ont besoin du bit d'exécution pour être traversés. Un répertoire avec la permission 644 (sans exécution) est effectivement inaccessible. Utilisez toujours 755 pour les répertoires, jamais 644.

Vous pouvez également consulter le journal d'erreurs PHP pour plus de détails :

sudo tail -50 /var/log/apache2/error.log
# ou pour Nginx :
sudo tail -50 /var/log/nginx/error.log

Permissions réinitialisées après un téléchargement FTP

Certains clients FTP définissent leurs propres permissions par défaut lors du téléchargement de fichiers. Vérifiez les paramètres de votre client FTP pour une option « permissions par défaut » ou « umask ». Configurez-le pour créer les fichiers en 644 et les répertoires en 755. Alternativement, exécutez les commandes de correction des permissions après chaque téléchargement FTP.

Bonnes pratiques de sécurité au-delà des permissions

Les permissions de fichiers correctes ne sont qu'une couche de sécurité. Considérez ces mesures supplémentaires :

• Restreindre l'accès aux fichiers de configuration : Le fichier app/config/parameters.php contient vos identifiants de base de données. Assurez-vous qu'il n'est lisible que par l'utilisateur du serveur web (permission 640), pas par tout le monde.
• Désactiver le listing de répertoires : Ajoutez Options -Indexes à votre configuration Apache ou autoindex off; à Nginx pour empêcher les visiteurs de parcourir le contenu des répertoires.
• Protéger les fichiers .htaccess : PrestaShop place des fichiers .htaccess dans les répertoires sensibles. Ne les supprimez pas.
• Supprimer le répertoire d'installation : Après l'installation, supprimez complètement le répertoire /install/. PrestaShop vous en avertit, mais il est important de le souligner.
• Définir un umask approprié : Configurez votre serveur web et PHP-FPM avec un umask de 0022 pour que les nouveaux fichiers soient créés avec les permissions 644/755 par défaut.

En comprenant les permissions Linux, en les adaptant à votre environnement d'hébergement et en suivant les recommandations de cet article, vous éviterez les problèmes de permissions PrestaShop les plus courants tout en maintenant une configuration serveur sécurisée.