Le Livre d'Argent

Les bases

Chaque fichier sur le disque est déterminé comme appartenant à un propriétaire, qui est un utilisateur du système, et à un groupe, qui est une sorte de rôle que peuvent prendre les utilisateurs (par défaut, un fichier appartient à l'utilisateur qui le crée, et au groupe principal de ce dernier (groupe qui porte le même nom que l'utilisateur)).

Basiquement, les trois accès possibles à un fichier sont les suivants :

• « r », droit en lecture. Permet d'afficher le contenu d'un fichier ou d'un répertoire.

• « w », droit en écriture. Permet de modifier le contenu d'un fichier, ou de créer/supprimer des fichiers dans un répertoire.

• « x », droit d'exécution. Permet de lancer le fichier comme si c'était un programme, ou de naviguer dans le répertoire.

Les droits d'accès d'un fichier sont les valeurs de ces trois accès pour le propriétaire du fichier, puis pour le groupe, puis pour les autres utilisateurs du système.

Par exemple, si un fichier appartient à l'utilisateur « machin » et au groupe « truc », et que ses droits d'accès sont « rwxr-xr-- »(1), cela signifie :

• Que l'utilisateur « machin » peut lire le fichier, écrire dedans, et l'exécuter (rwx).

• Que les membres du groupe « truc » (à l'exception de « machin ») peuvent lire le fichier et l'exécuter, mais pas écrire dedans (r-x).

• Que les autres utilisateurs du système (ceux qui ne sont ni « machin », ni membres du groupe « truc ») peuvent lire le contenu du fichier, mais ne peuvent rien faire d'autres (r--).

Dans les faits, les possibilités d'accès à un fichier dépendent des droits d'accès aux répertoires qu'ils contiennent. Par exemple, si vous avez le droit de lire un fichier, mais que vous n'avez pas le droit de naviguer dans le répertoire qui le contient, vous ne pourrez pas accéder au fichier.

À l'inverse, si vous n'avez pas le droit de modifier un fichier, mais que vous pouvez créer/supprimer des fichiers dans le répertoire qui le contient, rien ne vous empêche de supprimer le fichier en question et de le remplacer par un autre, ce qui revient à peu près au même que de le modifier (pas forcément tout-à-fait, mais je vous épargne les détails pointus).

La version intégrée et propre

C'est cette version que j'ai choisie sur mon serveur actuel.

Il s'agit simplement d'utiliser le fonctionnement de base du système, et principalement les accès du groupe. Par exemple, si je fais en sorte que tous les fichiers utilisés par le serveur web appartiennent au groupe « www-data », que tous les membres de ce groupe aient le droit en écriture sur ces fichiers, et que mon compte utilisateur appartient à ce groupe, je peux modifier ces fichiers sans problème.

Faire en sorte que mon compte utilisateur appartienne au bon groupe, c'est facile : il n'y a qu'une commande à lancer, et ça reste comme ça jusqu'à ce que je lance la commande inverse.

sudo adduser elzen www-data

Remplacez « elzen » par votre compte utilisateur à vous, et « www-data » par l'éventuel autre groupe concerné, bien sûr.

Faire en sorte que tous les fichiers du serveur web appartiennent au groupe www-data, c'est un poil plus complexe : comme on l'a vu, un fichier appartient par défaut au groupe principal de son propriétaire.

Les fichiers que l'utilisateur www-data, qui gère le site web, appartiennent donc bien au groupe www-data, mais les fichiers que je crée moi-même, eux, appartiennent par défaut au groupe « elzen ». Et je n'ai pas envie d'ajouter l'utilisateur www-data au groupe elzen.

Je peux lancer une commande (chown ou chgrp) pour changer le propriétaire et le groupe d'un fichier, mais ça n'affecte que les fichiers déjà présents, pas ceux que je n'ai pas encore créé.

Fort heureusement, il existe un mécanisme pour contourner ça : le « droit SGID ». Appliqué à un répertoire, ce droit particulier fait en sorte que tous les fichiers créés dans ce répertoire prennent, au lieu du groupe principal de leur propriétaire, le groupe auquel appartient le répertoire en question.

J'ai donc deux commandes à lancer :

sudo chown -R elzen:www-data /var/www
chmod -R g+s /var/www

La première affecte le répertoire /var/www (qui est le répertoire système censé contenir les fichiers du serveur web) à l'utilisateur elzen (donc, moi) et au groupe www-data. L'option « -R » rend la chose récursive, c'est-à-dire que tout le contenu de ce répertoire subira la même opération. La commande suivante ajoute (elle aussi récursivement) le droit SGID à ce répertoire.

Le gros avantage est que ce mécanisme est géré directement par le cœur du système, donc normalement, quel que soit l'outil utilisé, les fichiers créés dans /var/www (ou plus bas) appartiendront systématiquement à l'utilisateur qui les crée et au groupe www-data.

La difficulté, c'est de faire en sorte que les fichiers soient automatiquement modifiables par les membres de leur groupe. En effet, pour des raisons de sécurité, le « masque de droits » par défaut empêche de donner les droits d'écritures au groupe et aux autres utilisateurs.

Bien sûr, vous pouvez donner le droit d'accès en écriture à tous les fichiers déjà présents (chmod -R g+w /var/www), mais ça n'affectera pas les fichiers nouvellement créés.

Au niveau du CGI, vous pouvez sans doute régler ça facilement (dans PHP, la fonction umask fait ça très bien). Vous pourrez donc modifier les fichiers créés par le moteur du site ; mais il faudrait aussi l'accès inverse.

Dans un terminal, la commande umask vous permet de vérifier et de régler les droits qui seront donnés automatiquement à vos fichiers. Elle fonctionne avec trois chiffres en octal, comme les droits ci-dessus, mais à l'envers : le masque par défaut est « 0022 », ce qui représente (le premier zéro sert à indiquer que c'est de l'octal) « ----w--w- », qui sont les droits que l'on va retirer aux droits de base lors de la création d'un fichier.

En mettant ce masque par défaut à 0002 au lieu de 0022, on fait donc en sorte que les fichiers créés dans le shell courant conservent le droit d'écriture pour le groupe. Le truc est qu'il faut relancer la commande chaque fois qu'on ouvre un nouveau terminal, à moins de la mettre dans le fichier d'initialisation.

Pour les navigateurs de fichiers graphiques, comme Thunar ou Nautilus, il doit probablement exister un réglage adapté, mais comme je travaille sur mon serveur essentiellement en ligne de commande, je n'ai pas cherché comment ça se faisait.

Plus d'infos sur Wikipédia : SGID, umask.

La version fine et détaillée

Il existe une solution plus fine, extension de la gestion des droits natives, que j'utilisais sur mon ancien serveur : les ACL.

Cela permet de gérer, en plus des droits d'accès natifs, des permissions spécifiques pour chaque utilisateur (en gros, en plus de dire « les membres du groupe truc ont tels droits », vous dites directement « l'utilisateur machin a tel droit, l'utilisateur bidule a tel autre »).

Pour faire marcher ça, il faut ajouter l'option de montage « acl » à la partition sur laquelle se trouvent les fichiers concernés, donc si c'est sur une partition qu'il vaut mieux ne pas démonter en cours de route (la racine ou le home, par exemple), un redémarrage sera nécessaire.

Les ACL permettent donc une gestion détaillée, mais l'inconvénient est qu'il s'agit d'un truc en plus, qui n'est pas forcément bien géré par tous les outils de création de fichiers. L'une des raisons pour lesquelles j'ai abandonné cette pratique est que, sur mon ancien serveur, je devais régulièrement relancer le réglage des droits d'accès, à cause de fichiers qui n'avaient pas été correctement créés et ne reconnaissaient que les droits classiques.

La page de documentation sur laquelle je m'étais appuyé à l'époque pour mettre ça en place se trouve ici.

La version tarabiscotée

N'essayez pas ça chez vous, sauf si vous tenez à faire des bêtises. Cette solution est très probablement très mauvaise, mais elle me semble tellement amusante que je ne résiste pas à l'idée de vous en parler. Il s'agit de réaliser… des auto-montages réseaux locaux.

Il est en effet tout-à-fait possible de monter automatiquement des supports réseaux (sshfs, ftpfs, samba…) pour utiliser des ressources situées sur une autre machine comme si elles se trouvaient sur la machine active. Le principe est que vous connectez, par le réseau, un bout d'un disque dur distant dans l'arborescence locale, comme si vous montiez un support de stockage.

Or, votre machine peut à la fois être client et serveur, pour ces partages. Rien n'empêche donc, théoriquement, de monter un bout de votre disque dur local à un autre endroit de l'arborescence. Si vous montez, en tant qu'un utilisateur donné, un bout du disque, mais vous connectant en tant qu'un autre utilisateur, il devrait y avoir une sorte de changement automatique de propriétaire, qui permettrait à plusieurs utilisateurs d'avoir les mêmes accès sur certains répertoires.

Je tenterai ça, un jour, quand j'aurai le temps d'expérimenter des bizarreries.