Permissions sur un serveur web local : la rustine et la politique

Le problème, en une phrase

Sur un serveur Apache classique, le dossier racine (/var/www/html) appartient à root. Seul root peut y écrire — ni ton compte utilisateur, ni Apache lui-même (qui tourne sous l'utilisateur www-data) n'ont ce droit par défaut.

Deux besoins entrent alors en tension :

Toi, en tant que développeur, tu veux pouvoir éditer tes fichiers sans taper sudo à chaque nano.
www-data, l'utilisateur sous lequel tourne Apache, a parfois besoin d'écrire lui-même — typiquement dans des dossiers de cache, de logs, ou de stockage temporaire.

Le mauvais réflexe

Face à ce blocage, la tentation est de faire sudo chmod -R 777 /var/www/html. Ça fonctionne... et ça ouvre en écriture et en exécution à absolument tout le monde sur la machine. À proscrire, même en local.

Cas vécu : l'installation de phpBB

Lors de l'installation de phpBB sur poste local (Apache/PHP/MariaDB), l'installeur web a buté sur un fichier de cache corrompu, avec ce message :

"The installer has detected an issue with a cached file."

La cause : le dossier cache/ (et plus tard store/) devait être écrit par www-data, puisque c'est Apache qui exécute phpBB, pas notre compte personnel. La solution appliquée dans l'urgence a été :

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

Ça a débloqué l'installation — et c'est en soi une solution correcte pour ces dossiers précis. Mais c'est une rustine ciblée, pas une politique : elle ne règle que ces deux dossiers, sur ce projet précis. Au projet suivant, il faudra recommencer le même diagnostic.

Effet de bord à connaître

Avec chown www-data:www-data, c'est Apache qui devient propriétaire et groupe propriétaire. Ton propre compte utilisateur n'a alors plus aucun droit d'écriture sur ces dossiers — y compris pour un simple rm ou une édition manuelle. Il faudrait repasser par sudo à chaque intervention.

Une politique plus cohérente

L'idée, popularisée dans plusieurs guides d'administration Apache, est de séparer clairement deux rôles :

Propriétaire du dossier → l'utilisateur Apache (www-data), qui a besoin d'écrire dans certains sous-dossiers.
Groupe propriétaire → ton propre compte, ajouté au groupe www-data, pour pouvoir lire et écrire sans sudo.
Le reste du monde → aucun droit.

Mise en place, une seule fois pour tout `/var/www/html`

# 1. Ajouter son compte au groupe www-data (une seule fois, nécessite reconnexion)
sudo usermod -aG www-data $USER

# 2. www-data devient propriétaire, notre groupe devient groupe propriétaire
sudo chown -R www-data:$USER /var/www/html

# 3. Propriétaire (www-data) : lecture + exécution
#    Groupe (nous)          : lecture + écriture (+ exécution sur les dossiers, via X majuscule)
#    Le reste du monde      : rien
sudo chmod -R u=rx,g=rwX,o= /var/www/html

Le X majuscule dans chmod

Contrairement à x (minuscule), X majuscule n'ajoute le droit d'exécution qu'aux dossiers et aux fichiers déjà exécutables — jamais à un fichier PHP ou HTML classique. C'est ce qui permet de parcourir l'arborescence sans rendre tous les fichiers exécutables par erreur.

Après cette bascule initiale, il suffit de redonner l'écriture à www-data au cas par cas, uniquement là où c'est réellement nécessaire :

chmod -R u+w /var/www/html/phpBB3/cache
chmod -R u+w /var/www/html/phpBB3/store

(Remarque : ici, plus besoin de sudo pour cette dernière commande, puisque notre compte fait partie du groupe propriétaire.)

Ne pas oublier

Après le usermod -aG, l'appartenance au nouveau groupe n'est prise en compte qu'à la prochaine connexion. En attendant, newgrp www-data dans le terminal courant permet de tester sans se déconnecter.

Rustine vs politique : ce que ça illustre

	Rustine ciblée (`chown www-data:www-data` dossier par dossier)	Politique globale (`www-data:$USER` sur toute l'arborescence)
Rapidité	Immédiate, résout le blocage tout de suite	Demande une mise en place initiale
Portée	Un dossier, un projet à la fois	Toute l'arborescence, une fois pour toutes
Confort ensuite	`sudo` nécessaire pour toute intervention manuelle	Édition libre avec son propre compte
Reproductibilité	À refaire à chaque nouveau projet	Acquise pour tous les projets futurs
Où l'utiliser	Dépannage rapide, cas isolé	Environnement de développement durable

Les deux ne s'opposent pas vraiment : la rustine reste la bonne réponse dans l'instant, quand un installeur bloque et qu'il faut avancer. La politique globale, elle, évite de reproduire indéfiniment le même diagnostic à chaque nouveau projet hébergé sur la même machine.

Pour aller plus loin avec les élèves

Ce sujet se prête bien à une petite séquence progressive :

Constater le blocage — tenter d'écrire dans /var/www/html avec son compte personnel, observer le refus.
La rustine — chown www-data:www-data sur un dossier précis, comprendre pourquoi ça marche.
La politique — comprendre la séparation propriétaire / groupe / reste du monde, et pourquoi on préfère www-data:$USER à l'inverse ($USER:www-data) pour des outils qui, comme Nextcloud, vérifient parfois qu'ils sont bien propriétaires de leurs propres fichiers.
Le réflexe à éviter — expliquer pourquoi chmod 777 est une fausse bonne solution, même "juste pour tester en local".

C'est aussi une bonne occasion de rappeler la règle de fond des permissions Unix : ne donner que les droits strictement nécessaires, et rien de plus.

Page rédigée à partir d'un cas réel rencontré lors de l'installation de phpBB sur poste local, et d'un article de référence sur les permissions Apache/Ubuntu : le site de Yosko