Permissions des fichiers et répertoires d’un serveur web

Cet article établit une base de travail au niveau des permissions lors de la mise en place d’un serveur web hébergeant plusieurs sites pour plusieurs clients.

Un serveur HTTP peut contenir plusieurs sites, les fichiers de ceux-ci peuvent être gérés par plusieurs utilisateurs, un utilisateur A ayant accès aux fichiers du site A, mais pas à ceux du site B, alors qu’un utilisateur C, aura accès aux fichiers des site A, B et C par exemple.

Ce qui suit ne s’adresse pas à un type de serveur particulier, mais suppose une machine GNU/Linux et un serveur Nginx ou Apache.

Les permissions

Normalement sous Linux, lorsqu’un fichier est créé, il hérite du groupe de l’utilisateur qui l’a créé. Dans le cas de fichiers et répertoires relatifs à un serveur web, il est préférable que lorsqu’un fichier est créé il hérite du groupe du répertoire parent (en général /var/www), pour faire ceci il faut activer le bit SGID (Set Group ID) du répertoire parent.
Pour se rafraichir un peu les neurones au niveau du concept de permissions sous Linux, voir ce billet.

D’un autre coté, pour travailler convenablement avec ses collaborateurs, il faut prendre soin de modifier le umask, le masque de création de fichier par l’utilisateur, qui est général placé à 022 par défaut, c’est-à-dire que lorsqu’un fichier est créé il aura comme permissions 755, ce fichier n’étant pas éditable par le groupe. Changer le umask en 002 va placer les permissions d’un nouveau fichier en 775.

Principes de base

Dans un fonctionnement typique, nous voulons que les utilisateurs aient le droit de lire et écrire sur les fichiers. Ils doivent également avoir le droit d’exécution sur les répertoires, ce droit permettant à un utilisateur de traverser un répertoire, donc de lister ce qu’il contient.
De son coté le serveur web doit pouvoir lire et exécuter les fichiers. A noter qu’il n’a pas besoin d’avoir le droit d’exécution x car ceci ne s’applique en général qu’aux binaires, or un script PHP est un fichier texte interprété. Le serveur HTTP doit également pouvoir lire et « exécuter » les répertoires (entendre: il doit pouvoir les traverser). Enfin certains répertoires peuvent avoir le droit d’écriture pour donner le droit d’uploader des fichiers par exemple.

Configuration

La configuration sera la suivante : un groupe par site sera créé, les utilisateurs seront ajoutés aux groupes désirés afin d’y avoir accès et tous les fichiers et répertoires appartiendront à l’utilisateur root. La notion d’utilisateur n’étant plus importante dans notre cas, on ne fait qu’accroitre la sécurité du serveur web en attribuant la propriété des fichiers à l’utilisateur root (on est certain qu’aucun utilisateur du système n’aura les privilèges de modifier ces fichiers).

Voici un exemple qui peut servir de base :

  • On ajoute un groupe pour le site A :
    groupadd www-site-a
  • On fait de même pour le site B :
    groupadd www-site-b
  • On ajoute le groupe www-site-a à l’utilisateur A :
    usermod -a -G www-site-a usera
  • On ajoute le groupe www-site-b à l’utilisateur B :
    usermod -a -G www-site-b userb
  • Suivant l’exemple du début, on ajoute ces deux groupes à l’utilisateur C :
    usermod -a -G www-site-a userc
    usermod -a -G www-site-b userc

A ce stade on peut simplement vérifier les groupes des utilisateurs :

groups userc
userc : userc www-site-a www-site-b
  • On change les permissions de tous les fichiers et répertoires recursivement pour chaque site :
    chown -R root:www-site-a /var/www/site-a
    chown -R root:www-site-b /var/www/site-b
  • Tous les répertoires doivent avoir les droits 2775 :
    find /var/www -type d -exec chmod 2775 {} +
  • Tous les fichiers eux doivent être en 0664 :
    find /var/www -type f -exec chmod 0664 {} +

Pour finir, il faut changer le umask en 0002, cela diffère suivant le système. Sous Debian 7.4 ou Fedora 20, il est possible de changer la ligne UMASK du fichier /etc/login.defs.

Note sur les dangers du chmod 777

Un fichier ayant les droits 777 est accessible par tous les utilisateurs, n’importe lequel peut modifier et supprimer ce fichier. Ceci reste local aux utilisateurs existants sur la machine, c’est une question de confiance aux collègues. Plus important, des fichiers en 777 sont également modifiables par le serveur web lui-même, donc toute faille dans un script peut être catastrophique, une régle de base est de n’accorder qu’une confiance minimum à tout script, car aucun programme n’est à l’abri d’une vulnérabilité.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *