Yann "Bug" Dubois

La plupart des sites web nécessitent qu’une ou plusieurs personnes puissent intervenir pour modifier le contenu des fichiers et répertoires qui constituent le code du site web. Cela est vrai aussi bien pour les sites les plus simples constitués de pages statiques, que pour les sites les plus sophistiqués construits à partir de CMS comme WordPress et autres frameworks.

Selon la configuration du serveur web utilisé et les options de sécurité choisies, le serveur web (Apache ou NginX par exemple) opérera soit avec les mêmes droits que l’utilisateur “root” (ce qui lui permet d’accéder et de lire ou exécuter tous les fichiers, indépendamment de leur “propriétaire”, mais n’est pas du tout recommandable d’un point de vue sécurité), soit avec son propre compte utilisateur (par défaut sous Debian avec Apache2 il s’agira par exemple de l’utilisateur www-data, comme cela est configuré dans le fichier /etc/apache2/envvars).

(rappel : mon guide de configuration d’un environnement web LAMP complet sous Debian 6, par exemple sur un serveur dédié OVH ou Kimsufi, est ici)

Comment faire pour que les utilisateurs qui administrent le site web puissent avoir accès à tous les fichiers nécessaires dans le répertoire racine du site (en général /var/www sous Debian), tout en faisant en sorte que ces fichiers restent accessibles pour le serveur web ?

La solution nécessite trois caractéristiques du système de permission des fichiers sous GNU/Linux :

• Utiliser un groupe d’utilisateurs dans lequel nous placerons toutes les personnes qui doivent pouvoir administrer le contenu du site web;
• Utiliser le bit setGID pour les permissions des répertoires de l’arborescence du site web;
• Régler le umask des utilisateurs pour qu’ils puissent respectivement accéder en lecture ou écriture aux fichiers créés par chacun d’entre eux (alors que le serveur web lui-même n’a pas nécessairement besoin d’écrire des fichiers, ce qui évite des failles de sécurité).

Par ailleurs, nous réglerons de façon appropriée et récursivement toutes les permissions des fichiers et répertoires pré-existants dans le répertoire de publication web.

Création de comptes d’utilisateurs personnels

Chaque personne qui doit avoir accès à l’administration du contenu du site doit avoir un compte personnel (permet un minimum de traçabilité sur les actions de chacun). Ces comptes sont créés avec la commande :

sudo adduser <login>

Création du groupe d’administration web

On crée un groupe www-admin comme suit :

sudo addgroup www-admin

On place chacun des utilisateurs concernés dans le groupe avec la commande

sudo adduser <login> www-admin

Permissions sur les fichiers existants

sudo chown -R root:www-admin /var/www
sudo chmod -R 0664 /var/www

…on a attribué tous les fichiers existants à l’utilisateur root et au groupe www-admin, et on a autorisé tous les fichiers en lecture seule pour tout le monde (tous les autres utilisateurs), ce qui permettra à Apache (ou tout autre serveur web…) d’y accéder également sans privilège particulier. Les membres du groupe www-admin pourront en revanche également accéder en écriture à tout fichier.

Permissions sur les répertoires existants

cd /var/www
sudo find . -type d -exec chmod 2775 {} \;

… cette commande recherche tous les répertoires pour leur appliquer les droits avec le bit setGid. Ce réglage fait en sorte que tout fichier créé à l’intérieur d’un répertoire prend par défaut l’identifiant de groupe (Group ID = GID) du répertoire. Les fichiers créés par les administrateurs du site web dans son arborescence seront donc automatiquement attribués au groupe www-admin et pas au groupe de chaque utilisateur.

Réglage du umask des administrateurs du site

Deux possibilités :

• Changer pour tous les utilisateurs dans /etc/login.defs

UMASK           002

…ou…

• Changer uniquement pour les utilisateurs concernés

vi /home/<login>/.profile

umask 002

Ce réglage du umask (user mask = masque d’autorisations par défaut de l’utilisateur) est nécessaire pour que tous les administrateurs du site puisent accéder en écriture aux fichiers créés par d’autres administrateurs du site : en effet, ce “masque” fait en sorte que tout fichier créé sur le système par l’utilisateur concerné soit automatiquement créé avec la permission d’accès en écriture pour les membres du même groupe. Combiné au réglage setGID vu ci-dessus au niveau des répertoires, ce umask permet donc d’attribuer automatiquement un droit d’écriture sur tous les fichiers créés par un administrateur du site pour les membres du groupe www-admin.

Réglage des permissions pour les dossiers où le serveur web doit pouvoir écrire

…comme par exemple /wp-content/uploads pour WordPress

sudo chown -R www-data:www-admin /var/www/wp-content/uploads
sudo chmod -R 775 /var/www/wp-content/uploads

Dans ce cas, en donnant au serveur web la propriété des fichiers et des répertoires, on lui permet d’écrire, écraser ou supprimer les fichiers dans ces emplacements. Dans tous les autres cas, il vaut mieux que le serveur web ne soit jamais le propriétaire des fichiers (utiliser soit root, soit l’utilisateur qui a effectivement créé les fichiers en questions : c’est ce qui se passera une fois les configurations proposées ci-dessus appliquées).

A lire aussi :

• Configurer un serveur dédié OVH ou Kimsufi pour le web sous Debian 6 “Squeeze”
• Best way of handling Linux permission on Apache 2 (en anglais)
• WordPress Codex page on File permissions (en anglais)
• WordPress forum discussion on file permissions (en anglais)