Vous n'êtes pas identifié(e).
L'icône rouge permet de télécharger chaque page du wiki visitée au format PDF et la grise au format ODT →
Ceci est une ancienne révision du document !
Je propose d'aborder les concepts de droits unix et de type de fichier en prenant exemple sur la sortie de la commande :
ls -l
Ceci permettra d'aborder les droits sur les fichiers, les notions de propriétaires et de groupe et les divers types de fichiers qui existent sur un système de fichiers linux (ext2/ext3/ext4). La plupart de ces notions sont aussi vraies pour d'autres systèmes de fichiers unix, bien sûr ;)
Donc je vais d'abord exposer ces notions essentielles, et ensuite on va revenir sur des exemples pour entériner tout cela.
Faisons :
ls -l ~/.bashrc
-rw-r--r-- 1 enicar enicar 1436 avril 23 2014 /home/enicar/.bashrc
Donc nous allons décoder tout cela, en exposant quelques notions, puis nous reviendrons sur des exemples pratiques. Nous avons, de la gauche vers la droite :
champ | signification |
---|---|
-rw-r–r– | Types de fichiers, et permissions (c'est à dire les droits) |
1 | Le nombre de liens (Liens et inodes) |
enicar | Le propriétaire du fichier (Propriétaire et groupe) |
enicar | Le groupe à qui appartient le fichier (Propriétaire et groupe) |
1436 | La taille du fichier en octets |
avril 23 2014 | La date de dernière modification |
/home/enicar/.bashrc | Le nom du fichier |
Détaillons, le champ :
-rw-r--r--
Il est composé de 4 sous-champs. De la gauche vers la droite :
Dans un système de fichiers de type unix, il existe plusieurs types de fichiers. La commande « ls -l » utilise un caractère pour nous informer sur ce type :
Code | Type de fichier |
---|---|
- | Fichier normal |
d | Répertoire (directory) (Les répertoires) |
l | Lien symbolique (symbolic link) (Les liens symboliques) |
p | Tube nommé (pipe) |
s | Socket unix |
b | Périphérique avec accès de type bloc |
c | Périphérique avec accès de type caractère |
Les permissions sont stockées dans le premier inode (au moins) du fichier sous la forme d'un entier. Cet entier est un vecteur de bits. C'est à dire que chaque bit de cet entier à une signification soit pour le propriétaire, soit pour le groupe, soit pour les autres pour un droit en lecture, en écriture ou en exécution. C'est pour cela que je parlerai, par exemple, du bit de lecture pour le propriétaire. MAL DIT
Le champ des permissions est organisé en trois groupes qui correspondent aux permissions pour le propriétaire, pour le groupe et pour les autres. Pour chacun de ces groupes, trois attributs peuvent être positionnés ou non.
La signification pour les trois groupes des attributs « rwx » est :
Code | Signification |
---|---|
r | Accès en lecture autorisé |
w | Accès en écriture autorisé |
x | Droits d'exécution ou droit de faire un « cd » |
- | L'attribut n'est pas positionné |
Quelques exemples éclairciront les choses :
Code | Signification |
---|---|
rwx | Les droits en lecture, en écriture et en exécution sont positionnés |
— | Aucun droit |
r– | Droit en lecture uniquement |
r-x | Droit en lecture et en exécution |
À la place du x dans le champ rwx du propriétaire ou du groupe nous pouvons avoir :
Code | signification |
---|---|
S | Le bit setuid ou setgid est positionné, mais pas le droit en exécution |
s | Le bit setuid ou setgid est positionné ainsi que le droit en exécution |
On parle de setuid quand c'est l'attribut du propriétaire qui est positionné, et de setgid quand c'est l'attribut du groupe.
Par exemple :
ls -l /bin/su
-rwsr-xr-x 1 root root 38868 nov. 19 22:03 /bin/su
Ici, nous voyons que la commande « su » a son bit setuid positionné.
Pour terminer avec les droits, le champ « rwx » des autres (c'est à dire ceux qui ne sont ni le propriétaire, ni le groupe) peut prendre deux autres formes. À la place du x nous pouvons avoir.
code | Signification pour les répertoires |
---|---|
T | Dans ce répertoire seul les propriétaires des fichiers peuvent supprimer ces fichiers. Le bit en exécution pour les autres n'est pas positionné |
t | Même chose que précédemment, mais le bit en exécution pour les autres est positionné |
Dans linux, ce bit t n'est utilisé que pour les répertoires. Il est utilisé notamment pour les répertoires temporaires, par exemple 1)2) :
ls -ld /tmp
drwxrwxrwt 9 root root 8192 mars 20 20:25 /tmp
Nous voyons bien que le bit t est positionné.
Dans un système unix chaque fichier appartient à un utilisateur (que l'on appelle son propriétaire) et à un groupe. Chaque utilisateur fait aussi partie d'un groupe au moins (Voyez ce qu'affiche la commande « groups » pour votre utilisateur). La plupart du temps un fichier appartient à un groupe dont fait partie le propriétaire du fichier, mais ce n'est pas obligatoire. Aussi, il faut bien noter que le propriétaire et le groupe, même s'ils se nomment de la même façon, sont deux choses différentes.
Les groupes sont souvent utilisés pour gérer les droits plus finement ou pour réunir un ensemble d'utilisateurs sur les systèmes qui sont vraiment utilisés par plusieurs personnes.
Par défaut « ls -l » affiche la taille en octets. On peut obtenir un affichage plus parlant avec l'option « -h » (comme human readable, c'est à dire lisible pour un humain):
ls -lh ~/.bashrc
-rw-r--r-- 1 enicar enicar 1,5K avril 23 2014 /home/enicar/.bashrc
Nous obtenons la taille en kébi octets, dans ce cas mais pour des fichiers faisant plusieurs méga octets, « ls -lh » nous donnera la taille en mébi octets. C'est très pratique pour se faire une idée de la taille d'un fichier.
Par défaut « ls -l » affiche la date de dernière modification. Chaque fichiers, possèdent plusieurs horodatages. Il en existe 3 :
J'ai écrit entre parenthèses l’abréviation qui est employée pour chacune. On peut afficher ces trois dates à l'aide de la commande « stat » :
stat ~/.bashrc
Fichier : « /home/enicar/.bashrc » Taille : 1436 Blocs : 8 Blocs d'E/S : 4096 fichier Périphérique : fe05h/65029d Inœud : 6293947 Liens : 1 Accès : (0644/-rw-r--r--) UID : ( 1000/ enicar) GID : ( 1000/ enicar) Accès : 2015-03-19 22:10:12.848911153 +0100 Modif. : 2014-04-23 10:24:33.099434481 +0200 Changt : 2014-04-23 10:24:33.133434850 +0200 Créé : -
On voit les trois différentes dates. La date de dernière modification est changée lorsqu'on modifie les données du fichier. La date de dernier changement indique la date dernier changement des méta données concernant le fichier (c'est à dire, les informations, comme sa taille, son propriétaire, son groupe, ses droits, son nombre de liens,…). La date de dernier accès est changé lors d'un accès en lecture et aussi quand l'une des dates de modification ou de changement est changée.
On peut obtenir les dates de dernier accès et de dernier changement avec « ls -l ». Une option longue de la forme « –time=mode » permet de choisir quelle date afficher. Des options courtes sont aussi disponibles :
mode | option courte | affichage |
---|---|---|
atime, access ou use | -u | date de dernier accès |
ctime ou status | -c | date de dernier changement |
-t | date de dernière modification |
De plus, les options courtes trient selon la date sélectionnée.
Nous avons ici :
/home/enicar/.bashrc
ls n'affiche pas le nom des fichiers avec le chemin en entier. C'est le shell qui a substitué le « ~ » en « /home/enicar ». La même chose se passe quand on utilise un méta caractère du shell comme « * ». Pour vous en convaincre, comparez les sorties des deux commandes :
ls * echo *
Nous voyons que ls met en forme la sortie alors que echo fait juste un… écho !
Les données d'un fichier sont écrites sur le disque sous forme de blocs. L'information où se trouve ces blocs, est contenue dans un ensemble d'inodes (sous forme de numéros de blocs).
Cet ensemble d'inodes a un premier inode qui sert à référencer le fichier. Un répertoire fait correspondre un chemin (le nom du fichier) avec ce premier inode. De cette façon on peut avoir plusieurs noms pour le même fichier. Ces différents noms pointent sur le même premier inode.
Le nombre d'inodes utilisés par un fichier dépend évidemment de sa taille. Un seul inode ne suffit pas pour donner la liste de blocs, sauf pour les petits fichiers.
Le premier inode contient aussi les métadonnées associées au fichier. C'est à dire, sa taille, son propriétaire, son groupe, les dates de derniers changements, accès et modifications, le nombre de lien et les permissions.
Supposons à présent, que l'on ait deux noms de fichiers qui pointent sur le même inode. Donc, les données des « deux fichiers » sur le disque sont au même endroit. Et donc ils ont exactement les mêmes données. Leur métadonnées contenues dans le premier inode sont les mêmes également. On voit bien que les deux fichiers sont indiscernables.
Nous allons faire quelques expériences pratiques pour démontrer ce fonctionnement. J'ai dit plus haut que l'option -i permettait de connaître le numéro d'inode. C'est cette option que nous allons utiliser. Mais avant, nous allons créer un répertoire de test afin d'éviter de faire des bêtises…
mkdir ~/essai-de-liens cd ~/essai-de-liens
Vous devriez, à présent, vous trouver dans le répertoire essai-de-liens. Créons un nouveau fichier que nous allons appeler machin
touch machin
Nous pouvons vérifier que machin existe bien :
ls -l machin
-rw-r--r-- 1 enicar enicar 0 mars 21 17:02 machin
Donc le fichier existe, sa taille est nulle et son compteur de lien est égale à 1. Bien, on va créer un lien sur machin avec la commande ln :
ln machin bidule
Regardons les numéros d'inodes de nos deux fichiers :
ls -i machin bidule
6488098 bidule 6488098 machin
Le numéro d'inode sera différent chez vous, bien entendu. Mais ça devrait être le même numéro d'inode. C'est ce qui est important. Ça démontre que les deux fichiers sont en fait les mêmes ! Essayons, de modifier machin :
echo "je suis machin" >machin cat machin
je suis machin
Voyons à présent ce qu'il y a dans bidule
cat bidule
je suis machin
Voilà ! En modifiant, les données de machin nous avons modifié celle de bidule, car les deux fichiers ont les mêmes données sur le disque. Tenez, regardons le compteur de liens de nos deux fichiers :
ls -l bidule machin
-rw-r--r-- 2 enicar enicar 15 mars 21 17:11 bidule -rw-r--r-- 2 enicar enicar 15 mars 21 17:11 machin
Oh ! Le compteur de lien de machin a été incrémenté de 1, celui de bidule est aussi de 2 ! On va aller plus loin, grâce à la commande stat :
stat bidule machin
Fichier : « bidule » Taille : 15 Blocs : 8 Blocs d'E/S : 4096 fichier Périphérique : fe05h/65029d Inœud : 6488098 Liens : 2 Accès : (0644/-rw-r--r--) UID : ( 1000/ enicar) GID : ( 1000/ enicar) Accès : 2015-03-21 17:11:49.642004857 +0100 Modif. : 2015-03-21 17:11:43.670004690 +0100 Changt : 2015-03-21 17:11:43.670004690 +0100 Créé : - Fichier : « machin » Taille : 15 Blocs : 8 Blocs d'E/S : 4096 fichier Périphérique : fe05h/65029d Inœud : 6488098 Liens : 2 Accès : (0644/-rw-r--r--) UID : ( 1000/ enicar) GID : ( 1000/ enicar) Accès : 2015-03-21 17:11:49.642004857 +0100 Modif. : 2015-03-21 17:11:43.670004690 +0100 Changt : 2015-03-21 17:11:43.670004690 +0100 Créé : -
Vous pouvez vérifier que pour bidule et machin les dates de derniers accès sont les mêmes. Il en est de même pour les dates de changements et dernière modifications. Les deux fichiers sont indiscernables, tant au niveau de leur données que de leurs métadonnées.
Supprimons machin :
rm machin
Voyons, ce qu'il y a dans bidule :
cat bidule
je suis machin
Le fichier bidule existe toujours, ses données n'ont pas changé.
Les répertoires sont des fichiers avec l'attribut « répertoire » 3)
Les répertoires permettent de faire la correspondance entre les noms des fichiers et les inodes. Les répertoires ont eux mêmes un nom dans un répertoire, à l'exception du répertoire racine qui n'a pas de nom.
Nous allons voir que les répertoires sont aussi des liens sur des inodes, et qu'un répertoire possède d'office plusieurs liens physiques (à par la racine, mais ça ne dure pas longtemps ). Donc, voyons le nombre de liens d'un répertoire. Pour cela nous allons utiliser, l'option -d de ls, par exemple :
ls -ld .
Cela donne dans mon home :
drwxr-xr-x 246 enicar enicar 36864 mars 26 06:42 .
Nous voyons que le répertoire courant a bien l'attribut répertoire (ouf !). Le nombre de liens est 246, et sa taille 36864 octets.
Le nombre de liens d'un répertoire est au moins deux 4). En effet, le premier lien est celui du répertoire parent. Le second est celui qu'il a sur lui même, c'est le point. Alors nous en arrivons à la question : d'où vient ce 246 ? À chaque nouveau sous-répertoire créé dans un répertoire est associé un lien noté ... Ce lien pointe sur le répertoire parent. Donc on en déduit, qu'il y a 244 sous-répertoires dans le répertoire courant de mon exemple. Prouvons le ! Je vais utiliser pour ce faire les commandes find et wc. find permet de chercher des fichiers selon divers critères. Ici, je vais lui demander de trouver les répertoires du répertoire courant (-type d) et de ne pas parcourir ces sous-répertoires en profondeur comme il le fait normalement (-maxdepth 1). wc compte les caractères, les mots et les lignes. Ici, je lui demande de compter les lignes uniquement (-l)
find . -maxdepth 0 -type d |wc -l
find permet de chercher des fichiers selon divers critères. Ici, je vais lui demander de trouver les répertoires du répertoire courant (-type d) et de ne pas parcourir ces sous-répertoires en profondeur comme il le fait normalement (-maxdepth 1). wc compte les caractères, les mots et les lignes. Ici, je lui demande de compter les lignes uniquement (-l). En effet, par défaut, find affiche un fichier par ligne. Mais surprise ! Cela affiche :
245
Me serais-je fourvoyer ? Non, pas du tout ! En fait, avec find nous avons aussi compté le répertoire courant (c'est à dire .). Vous pouvez le vérifier en faisant :
find . -maxdepth 1 -type d |less
Le répertoire . devrait être listé au début. Une autre façon de voir, est que find lise tous les répertoires du répertoires courant sauf .., ça nous fait 246-1. Le compte est bon !
à suivre.