Fichiers, répertoires et droits - Linux Magazine France No 4

Ou comment ne pas se perdre sous Linux. Nous commençons, avec cet article, une série de plusieurs articles permettant aux nouveaux arrivants sous Linux de prendre plus facilement contact avec un environnement parfois trop riche. Ce mois-ci, nous allons voir comment le système gère les fichiers et quelles informations sont nécessaires pour comprendre les liens, les droits, etc.

Les noms des fichiers sont libres. Il n'existe pas de relation entre l'extension (facultative) et le type de fichier, comme c'est le cas sous DOS. Plus exactement, s'il y a une relation, elle est liée au logiciel utilisé, mais en aucun cas au système. De plus, Unix (et donc Linux) distingue les majuscules des minuscules dans les noms de fichier. Vous pourrez donc trouver les fichiers Toto, toto, TOTO, etc. dans le même répertoire

Sous Unix, un même fichier peut avoir plusieurs noms : c'est ce qu'on appelle un "lien dur". On les crée avec la commande ln. Par exemple, si j'ai un fichier toto, et si je tape la commande ln toto titi, j'obtiens titi qui est un nouveau lien dur sur le fichier toto. toto et titi représentent le même fichier : si je modifie titi, les changements apparaîtront aussi dans toto. En effet, il existe un seul exemplaire du fichier sur le disque : la création d'un lien dur ne prend aucun espace disque.

A partir de ce moment, toto et titi sont deux liens vers le même fichier. Ils sont parfaitement égaux, aucun des deux ne représentant le fichier plus que l'autre. Si maintenant j'efface toto, le fichier existe encore sous le nom de titi. Un fichier est définitivement supprimé quand son dernier lien est effacé.

Les liens durs ont pas mal de défauts : notamment, l'ensemble des liens d'un fichier doivent être sur le même disque physique et les liens sur des répertoires posent des problèmes de boucles avec les programmes qui examinent toute une arborescence. A part dans quelques cas précis, on considère qu'il est préférable d'employer des liens symboliques. Comme un lien dur, un lien symbolique est un alias d'un fichier. Mais contrairement au lien dur, le lien symbolique n'est qu'un alias : on distingue bien le fichier lui-même et les liens, qui ne veulent plus rien dire si le fichier est effacé.

Par exemple, j'ai toujours mon fichier toto et je veux créer un lien symbolique titi. Pour cela, je tape ln -s toto titi. Si vous tapez un ls -l, vous pourrez voir clairement le lien :

Là encore, si je modifie toto, titi sera également affecté, et vice-versa. Par contre, si j'efface toto et que je veux ensuite modifier titi, le système va m'insulter : titi est un lien symbolique invalide, puisque le fichier qu'il désignait a disparu.

Il existe d'autres types de fichiers spéciaux plus exotiques. Les principaux, que nous utiliserons peut-être par la suite :

- les périphériques : pour communiquer avec un périphérique, on lit ou on écrit dans un fichier spécial représentant ce périphérique.

- les tubes : on les utilise parfois pour enchaîner des commandes : une commande écrit dans le tube, une autre y lit.

Contrairement à MS-DOS, Unix voit ses disques comme une arborescence unique. Une partition contient la racine du système de fichier, qu'on note / (et non c:\ comme sous MS-DOS). D'autres partitions, des disquettes, des CD-ROM, etc., peuvent être "montés" dans des répertoires. Par exemple, sur la machine que j'utilise en ce moment, le contenu du CD-ROM est accessible dans le répertoire /mnt/cdrom. Une fois les différents systèmes de fichiers montés, leur utilisation est transparente, sauf dans quelques cas particuliers, comme l'impossibilité d'écrire sur un CD-ROM par exemple. Bien souvent, sur les systèmes importants, les utilisateurs ne savent même pas dans quelle machine se trouve le disque dur qu'ils utilisent.

La structure "standard" des répertoires est décrite par le FHS (Filesystem Hierarchy Standard), auquel la plupart des distributions Linux essayent de se conformer.

Après avoir jeté un oeil à votre arborescence, vous vous demanderez sans doute pourquoi /, /usr et /usr/local ont des structures similaires. Explication : Il est assez fréquent que /usr soit stocké sur un disque distinct de /, voire sur une autre machine. Donc / contient de quoi monter /usr, y compris à travers le réseau, et de quoi réparer si un problème survenait. La même remarque s'applique à /home ; c'est pourquoi le répertoire de l'administrateur est /root et non /home/root. De plus, comme /usr peut être monté en réseau, il peut être partagé entre plusieurs machines ; c'est pourquoi les fichiers de config et de données sont dans /var.

Quant à /usr/local, il est séparé de /usr car si /usr est facilement récupérable en cas de pépin (au pire, on réinstalle tout), /usr/local est beaucoup plus difficile à reconstruire : il faut récupérer les sources des logiciels et les recompiler.

Enfin, /opt a une structure totalement différente : chaque logiciel y a son propre répertoire. On pourra, par exemple, avoir une hiérarchie du style:

Généralement, chaque répertoire de /opt possède au moins les sous-répertoires bin, lib, etc., qui contiennent respectivement les exécutables et les fichiers de config :

Unix est multi-utilisateurs. Pour cette raison, tout le monde ne peut pas tout faire, à part l'administrateur système (traditionnellement nommé root), qui a le droit de lire et d'écrire tous les fichiers de tous les répertoires.

Chaque utilisateur est désigné de manière unique par son login (son "nom"). De plus, chaque utilisateur appartient à un ou plusieurs groupes. Par exemple, sous Red Hat Linux, chaque utilisateur est par défaut seul membre de son groupe personnel et membre du groupe users. Ainsi, sur ma machine, j'ai un utilisateur arnaud qui est membre des groupes arnaud et users. L'intêret d'avoir chaque utilisateur unique membre d'un groupe dépasse le cadre de cet exposé ; pour ceux que ça intéresse, c'est expliqué dans le manuel d'installation de Red Hat, au chapitre 11.

Un fichier ou un répertoire appartient toujours à un utilisateur et à un groupe. D'autre part, un fichier peut être accessible en lecture, en écriture et en exécution. Les permissions sont distinctes pour l'utilisateur propriétaire du fichier, pour le groupe propriétaire et pour le reste du monde. Ces permissions sont affichées par la commande ls quand on lui rajoute l'option -l:

Cette ligne signifie que le fichier toto appartient à l'utilisateur arnaud et au groupe users, avec les droits -rw-r--r--. Les autres valeurs (1, 1055740 et la date) ne nous intéressent pas ici. Mais à quoi correspondent les permissions -rw-r--r--? J'y viens. Le premier caractère représente le type de fichier : "-" pour un bête fichier normal, "d" pour un répertoire, "p" pour un tube, "b" ou "c" pour un périphérique, "l" pour un lien symbolique. Les trois suivants représentent les droits de l'utilisateur propriétaire du fichier. "r" représente le droit de lecture, "w" le droit d'écriture et "x" le droit d'exécution. Ici, "rw-" signifie que l'utilisateur arnaud peut lire et écrire dans le fichier, mais pas l'exécuter. Les trois caractères suivants représentent les permissions du groupe ; ici, tous les membres du groupe users peuvent lire le fichier, mais pas y écrire, ni l'exécuter. Enfin, les trois derniers caractères ont une signification analogue pour le reste du monde. Une petite nuance pour les répertoires : si un utilisateur a le droit “d'exécution" sur un répertoire, cela signifie qu'il peut s'y rendre avec la commande cd ou équivalent. Enfin, notez que pour effacer un fichier, il n'est pas nécessaire de pouvoir y écrire ; il suffit d'avoir le droit d'écrire dans le répertoire le contenant.

Chacun des 9 derniers caractères représente une valeur vraie ou fausse. En informatique, on représente ça par un bit. On a donc trois groupes de trois bits, c'est à dire trois chiffres octaux (en base 8), représentés comme suit :

Par exemple, un groupe "rwx" est représenté par 4+2+1=7. Un groupe "r--" par 4+0+0=4. Un groupe "--x" par 0+0+1=1. Ainsi, les permissions rw-r--r-- de notre fichier toto s'écrivent 644.

Quand un fichier est exécutable par son propriétaire, il peut de plus être setuid. Cela signifie que lorsqu'il est exécuté, il l'est avec les droits de son propriétaire, et non avec ceux de l'utilisateur qui le lance. Par exemple, le programme passwd, qui permet à un utilisateur de modifier son mot de passe, est setuid root (c'est à dire qu'il est setuid et qu'il appartient à l'utilisateur root) : il doit pouvoir écrire dans le fichier /etc/passwd (ou /etc/shadow), dans lequel seul root peut écrire.

De la même façon, un exécutable peut être setgid, et s'exécuter avec les droits du groupe auquel il appartient.

Enfin, un exécutable peut être "sticky" (on dit aussi "avoir le sticky bit positionné"): cela signifie qu'il reste en mémoire même après la fin de son exécution, pour pouvoir être relancé plus rapidement. Alors qu'un exécutable peut être déclaré setuid et setgid par son propriétaire, seul l'administrateur système peut positionner le sticky bit.

Pour les répertoires, les setgid et sticky bit prennent une signification différente. Quand un répertoire est setgid, tous les fichiers créés dans ce répertoire appartiennent au même groupe que le répertoire. C'est utilisé par exemple quand plusieurs personnes travaillent sur un projet commun. Ils ont alors un groupe dédié à ce projet, un répertoire setgid appartenant à ce groupe, et ils créent leurs fichiers dans ce répertoire avec les permissions 664 . Tout le groupe peut alors écrire n'importe quel fichier, vu que tous les fichiers appartiennent au groupe.

Voyons maintenant l'utilisation du sticky bit. Comme je l'ai écrit plus haut, un utilisateur qui a le droit d'écrire dans un répertoire peut effacer n'importe quel fichier de ce répertoire. Cela peut être très gênant par exemple pour le répertoire /tmp, dans lequel tout le monde a généralement le droit d'écrire. Pour y remédier, on positionne le sticky bit ; ainsi, un utilisateur ne peut effacer que les fichier qui lui appartiennent.

Lorsqu'on écrit les permissions en octal, setuid, setgid et sticky bit sont représentés par une nouvelle série de 3 bits, qui se place avant les 3 autres séries: setuid=4, setgid=2, sticky=1. Ainsi, sur ma machine, le serveur de mail /usr/sbin/sendmail a les droits rwsr-sr-x (rwxr-xr-x, setuid, setgid); en octal, ça donne 6775. n

© Copyright 2000 Diamond Editions/Linux magazine France. - Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1or any later version published by the Free Software Foundation; A copy of the license is included in the section entitled "GNU Free Documentation License".