Recherche de fichiers

Recherches de binaires avec which

Tu peux rapidement être perturbé par les commandes sous Linux, est-ce une commande interne, un binaire ou encore une fonction ? Pour t’aider tu peux utiliser l’outil type qui te dira de quel type (je me suis pas foulé) est la commande que tu lances et dans certains cas type t’indiquera même où est stockée la-dite commande. Regarde le type de cheat et de uname.

antoine@dressing:~$ type cheat
cheat est une fonction
cheat () 
{ 
    curl "https://cheat.sh/$1"
}
antoine@dressing:~$ type uname
uname est /usr/bin/uname

Bien que type soit pratique pour déterminer si une commande est un alias, un binaire ou une fonction, ce n’est pas le premier outil que tu devrais utiliser pour trouver un binaire.

locate est l’outil le plus rapide parmi ceux que je vais te présenter dans ce module pour retrouver n’importe quel type de fichier dans l’intégralité du disque dur. Il a cependant deux désavantages : il n’est pas installé par défaut (peut-être dans certaines distributions) et il s’appuie sur une base de données (et c’est la raison pour laquelle il est si rapide).

root@debian:~# locate
-bash: locate : commande introuvable

# Ok, on l'installe alors

root@debian:~# apt install locate
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait      
Les NOUVEAUX paquets suivants seront installés :
  locate
0 mis à jour, 1 nouvellement installés, 0 à enlever et 12 non mis à jour.
Il est nécessaire de prendre 240 ko dans les archives.
Après cette opération, 383 ko d'espace disque supplémentaires seront utilisés.
Réception de :1 http://deb.debian.org/debian bookworm/main amd64 locate amd64 4.9.0-4 [240 kB]
240 ko réceptionnés en 2s (126 ko/s)
Sélection du paquet locate précédemment désélectionné.
(Lecture de la base de données... 27602 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../locate_4.9.0-4_amd64.deb ...
Dépaquetage de locate (4.9.0-4) ...
Paramétrage de locate (4.9.0-4) ...
'
# Alors, où est uname ? :S

root@debian:~# locate uname
root@debian:~# 

# Oui, par défaut sa base de données est vide ! On va la peupler (ce qui peut être long selon la taille de ton disque et la quantité de fichiers à indexer).

root@debian:~# updatedb
root@debian:~# locate uname
/etc/update-motd.d/10-uname
/usr/bin/uname
/usr/lib/klibc/bin/uname
/usr/share/man/man1/uname.1.gz

Il faudra tenir la base de données à jour pour que les nouveaux fichiers soient indexés ce qui peut prendre un temps certain selon la taille et la technologie du disque.

whereis au contraire n’entretient pas de base de données mais ne recherche que dans le $PATH. Afin de vérifier où il va chercher, on peut afficher le contenu de cette variable d’environnement.

root@debian:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@debian:~# whereis uname
uname: /usr/bin/uname /usr/share/man/man1/uname.1.gz

Tu remarqueras deux choses. Avec locate comme avec whereis, on retrouve le binaire /usr/bin/uname comme sa page de manuel /usr/share/man/man1/uname.1.gz. Cependant, whereis ne remonte pas /etc/update-motd.d/10-uname vu que le chemin ne fait pas partie de mon $PATH.

whereis possède quelques options afin de ne retourner que les binaires, les sources ou les pages de manuel mais à une limitation, lorsqu’il retourne plusieurs binaires différents, il ne t’indiquera pas lequel tu exécutes.

root@debian:~# whereis -b vim # binaires
vim: /usr/bin/vim /etc/vim /usr/share/vim
root@debian:~# whereis -m vim # manuel
vim: /usr/share/man/man1/vim.1.gz
root@debian:~# whereis -s vim # source
vim: # y en a pas

which fonctionne un peu comme whereis parce qu’il va chercher dans le $PATH mais ne va retourner que le binaire qui sera lancé lorsque l’on valide une commande. Tu peux quand même lui faire cracher toutes les instances avec le commutateur -a.

root@debian:~# which vim
/usr/bin/vim
root@debian:~# which -a vim
/usr/bin/vim
/bin/vim

Rechercher des fichiers avec find

find est l’outil ultime lorsque les autres commandes (which, whereis ou si locate n’est pas installé) n’ont pas retourné de résultat probant. Il va rechercher dans tout le disque dur. find a une syntaxe particulière qui contrevient aux standards Unix : ses commutateurs utilisent un simple tiret pour des noms longs.

En lançant une recherche sur la / en tant qu’utilisateur, on se retrouvera avec beaucoup de messages d’erreurs de permission alors on jettera les erreurs à la poubelle.

antoine@dressing:~$ find / -name gitpuller.sh 2> /dev/null
/home/antoine/scripts/gitpuller.sh

Tu peux bien entendu utiliser des * pour chercher tous les fichiers pdf par exemple find / -name *.pdf mais également chercher des éléments par taille. Imagine que je veuille trouver les fichiers de plus de 2Go.

antoine@dressing:~$ find / -size +2G 2> /dev/null
/home/antoine/Documents/ISO/debian-12.8.0-amd64-DVD-1.iso
/home/antoine/Téléchargements/9781835885406.zip
/home/antoine/VirtualBox VMs/LABANSIBLE/LAB-BASTION-01/TemplateDebian12-disk001.vmdk

Tu peux aussi chercher selon les permissions. La syntaxe est un peu étrange mais admets que tu veuilles chercher des fichiers de ta home dont les permissions de group et de other permettent d’y écrire.

antoine@dressing:~$ find ~/ -perm /g=w,o=w
[...]
/home/antoine/.config/google-chrome/SingletonSocket
/home/antoine/.config/google-chrome/SingletonLock
/home/antoine/.config/google-chrome/SingletonCookie
[...]

Tu peux aussi chercher les fichiers qui appartiennent à un utilisateur ou à un groupe selon son nom ou son ID.

antoine@dressing:~$ find /usr/share -user antoine
antoine@dressing:~$ whoami
antoine
antoine@dressing:~$ id antoine
uid=1000(antoine) gid=1000(antoine) groupes=1000(antoine),100(users),110(bluetooth)
antoine@dressing:~$ find /usr/share -uid 1000
antoine@dressing:~$ find /usr/share -gid 1000

find est récursif par défaut et c’est très puissant mais parfois on peut vouloir limiter la profondeur de la recherche.

antoine@dressing:~$ sudo find /etc -maxdepth 1 -name ssh
/etc/ssh

# Attention, 1 est le minimum ; en dessous find ne fera pas la recherche

Rechercher des fichiers avec grep

Tu peux te souvenir d’une partie du contenu d’un fichier sans te rappeler le chemin exact dudit fichier. Dans le précédent article on a parlé de fgrep et de egrep pour chercher des chaînes fixes ou des expressions régulières. Ici on va parler de rgrep ou plutôt de grep -r (l’alias n’existe pas dans toutes les distros) qui permet de chercher récursivement dans le contenu des fichiers.

Dans ton dossier scripts, tu veux par exemple rechercher les fichiers qui intègrent le mot « Progress ». On mettra le(s) terme(s) recherché(s) entre guillemets pour bien adresser la recherche et segmenter notre commande et le dossier dans lequel procède la recherche.

antoine@dressing:~$ grep -r "Progress" scripts/
scripts/gitpullerdemo.sh:# Progress bar  dedicated variables
scripts/gitpuller.sh:# Progress bar  dedicated variables

J’ai l’impression qu’il manque un paquet de choses, ça peut être lié à la casse de « P ».

antoine@dressing:~$ grep -r "[P,p]rogress" scripts/
# [...]
scripts/gitpullerdemo.sh:# purpose: progress bar
scripts/gitpullerdemo.sh:# Progress bar  dedicated variables
# [...]
scripts/thomasjefferson.txt:Pour apprendre, il faut écouter. Pour progresser, il faut essayer.
# [...]
scripts/gitpuller.sh:# purpose: progress bar
scripts/gitpuller.sh:# Progress bar  dedicated variables
# [...]

Il doit y en avoir encore mais je vais pas faire une regex pour chaque lettre ? Si ? Mais si le terme recherché fait 72 caractères ? Tu insensibiliseras grep à la casse avec -i.

antoine@dressing:~$ grep -ri "Progress" scripts/
# [...]
scripts/gitpullerdemo.sh:# purpose: progress bar
scripts/gitpullerdemo.sh:# Progress bar  dedicated variables
scripts/gitpullerdemo.sh:PROGRESS_BAR_CHAR=(█ ▒)
# [...]
scripts/thomasjefferson.txt:Pour apprendre, il faut écouter. Pour progresser, il faut essayer.
# [...]
scripts/gitpuller.sh:# purpose: progress bar
scripts/gitpuller.sh:# Progress bar  dedicated variables
scripts/gitpuller.sh:PROGRESS_BAR_CHAR=(█ ▒)
# [...]

Bon c’est bien gentil tout ça mais voir s’afficher chaque ligne qui contient « progress » ça pollue mon shell, moi je veux juste voir les nom des fichiers qui le contiennent. On va alors demander à grep de seulement lister les fichiers avec le commutateur -l.

antoine@dressing:~$ grep -ril "Progress" scripts/
scripts/.git/logs/HEAD
scripts/.git/logs/refs/heads/main
scripts/.git/hooks/pre-push.sample
scripts/gitpullerdemo.sh
scripts/thomasjefferson.txt
scripts/gitpuller.sh

Si tu peux rechercher des fichiers qui contiennent une chaîne, tu peux aussi rechercher des fichiers qui ne contiennent pas cette chaîne. Ainsi, si tu cherches quelles pizzas contiennent des champignons ou non grep est l’outil qu’il te faut : il y en a dans la royale et dans la regina, mais pas dans la margarita ni dans la reine (je ne suis pas italien ni docteur en pizzaiologie alors moi ça ne me dérange pas que la reine et la regina soient deux pizzas différentes).

root@debian:~/recettes_de_pizza# ls
margarita.txt  quatre_fromages.txt  regina.txt  reine.txt  royale.txt
root@debian:~/recettes_de_pizza# cat royale.txt regina.txt 
tomate, jambon, oeuf, champignon, mozzarella, olive
tomate, jambon, champignon, mozzarella
root@debian:~/recettes_de_pizza# cat margarita.txt reine.txt quatre_fromages.txt 
tomate, mozzarella, origan
tomate, jambon, mozzarella
tomate, mozzarella, camembert, cheddar, bleu

root@debian:~/recettes_de_pizza# grep -rl champignon . # Avec
./royale.txt
./regina.txt
root@debian:~/recettes_de_pizza# grep -rlv champignon . # Sans
./margarita.txt
./reine.txt
./quatre_fromages.txt

Ca y est, je crois que j’ai la dalle.

Liens physiques et liens symboliques

Un lien physique (hard link) est créé lors de la création d’un fichier, il lie l’emplacement du fichier dans le système de fichier à son emplacement réel au niveau des inodes. On peut créer plusieurs liens physiques vers un même fichier et la suppression de l’un d’eux ne supprime pas les autres. Le fichier est détruit lors de la suppression du dernier lien physique. Les liens physiques ne fonctionnent cependant que sur un même volume (disque ou partition). L’intérêt est donc de ne stocker qu’une seule fois un fichier mais de pouvoir y accéder depuis plusieurs endroits.

A l’inverse, un lien symbolique créé un raccourci vers l’emplacement d’un fichier initial. En cas de suppression du fichier initial, le lien symbolique n’est plus fonctionnel.

Donc si je souhaite utiliser le nom italien pour ma pizza quatre fromages, je peux très bien utiliser un lien physique.

root@debian:~/recettes_de_pizza# ln quatre_fromages.txt quattro_fromaggi.txt
root@debian:~/recettes_de_pizza# ls -l| grep qua
-rw-r--r-- 2 root root 45  3 janv. 06:50 quatre_fromages.txt
-rw-r--r-- 2 root root 45  3 janv. 06:50 quattro_fromaggi.txt

Tu remarqueras qu’on ne voit pas l’emplacement du système de fichier auquel est stocké l’autre lien physique, le système n’en a aucune idée. Mais tu peux remarquer le « 2 » de la seconde colonne qui montre le nombre de liens physiques du fichier. Si je supprime quatre_fromage.txt, le contenu du fichier survit.

Comprendre le fonctionnement des liens physiques aide dans un sens à réaliser pourquoi la somme de contrôle d’un fichier (vu dans le précédent article) n’est pas dépendante du nom du fichier. C’est bien le contenu qui est hashé, pas les métadonnées qui l’accompagnent – dont le nom.

root@debian:~/recettes_de_pizza# rm quatre_fromages.txt 
root@debian:~/recettes_de_pizza# cat quattro_fromaggi.txt 
tomate, mozzarella, camembert, cheddar, bleu

Si la quat’fro est ma pizza préférée du moment, je peux très bien le signifier en utilisant un lien symbolique.

root@debian:~/recettes_de_pizza# ln -s quattro_fromaggi.txt ma_pizza_preferee.txt
root@debian:~/recettes_de_pizza# ls -l | grep qua
lrwxrwxrwx 1 root root 20  4 janv. 13:58 ma_pizza_preferee.txt -> quattro_fromaggi.txt
-rw-r--r-- 1 root root 45  3 janv. 06:50 quattro_fromaggi.txt

Là le nombre de lien est repassé à 1 mais surtout tu voies que ma_pizza_preferee.txt est un lien vers quattro_fromaggi.txt. Par contre, si je renomme de nouveau en français ma pizza, ça brisera mon lien symbolique. Le lien symbolique est bien dépendant du chemin du fichier original.

root@debian:~/recettes_de_pizza# mv quattro_fromaggi.txt quatre_fromages.txt
root@debian:~/recettes_de_pizza# ls -l | grep ma_pizza
lrwxrwxrwx 1 root root 20  4 janv. 13:58 ma_pizza_preferee.txt -> quattro_fromaggi.txt
root@debian:~/recettes_de_pizza# cat ma_pizza_preferee.txt 
cat: ma_pizza_preferee.txt: Aucun fichier ou dossier de ce type

En dehors de cet exemple ridicule, l’usage d’un lien symbolique est pratique pour lier une version particulière d’un logiciel ma_pizzeria_v2.1.7 vers ma_pizzeria de sorte que lorsque la version évolue, tu ne changes que le lien symbolique.

Permissions sur les fichiers

Appartenance d’un fichier (File ownership)

Dans le monde Unix, un fichier ou un dossier doit avoir un propriétaire. C’est un mécanisme de sécurité qui fait que quelque soit les réglages de permissions qui y sont appliqués, le propriétaire aura toujours accès. Afficher le propriétaire d’un fichier ou d’un dossier est particulièrement simple et se fait à l’aide de ls -l. C’est l’information de la troisième colonne juste après les permissions et le nombre de liens.

antoine@dressing:~$ ls -l scripts/
-rwxr-xr-x 1 antoine antoine 3213 21 juin   2024 gitpullerdemo.sh
-rwxr-xr-x 1 antoine antoine 3222 24 juin   2024 gitpuller.sh
-rw-r--r-- 1 antoine antoine   68  3 janv. 18:37 thomasjefferson.txt

On parle de la première mention de « antoine ». La seconde est un groupe du même nom. Sur Linux lorsque tu créé un utilisateur, un groupe du même nom est créé (par défaut, ne chipote pas) et tout ce petit monde possède son id.

antoine@dressing:~$ id
uid=1000(antoine) gid=1000(antoine) groupes=1000(antoine),100(users),110(bluetooth)

Tu peux être amené à devoir changer le propriétaire d’un fichier et là c’est pas non plus compliqué à deviner et retenir si tu as quelques notions d’anglais : chown pour change owner. Mettons que je veuille que ce soit toi le propriétaire.

antoine@dressing:~$ sudo useradd toi
antoine@dressing:~$ chown toi scripts/gitpuller.sh
chown: modification du propriétaire de 'scripts/gitpuller.sh': Opération non permise
antoine@dressing:~$ sudo chown toi scripts/gitpuller.sh

Par mesure de sécurité, l’opération n’est pas permise sans élévation de privilèges sudo ou directement en tant que root.

antoine@dressing:~$ ls -l scripts/
-rwxr-xr-x 1 antoine antoine 3213 21 juin   2024 gitpullerdemo.sh
-rwxr-xr-x 1 toi     antoine 3222 24 juin   2024 gitpuller.sh
-rw-r--r-- 1 antoine antoine   68  3 janv. 18:37 thomasjefferson.txt

C’est bien toi le nouveau propriétaire du fichier mais tu l’as remarqué, le groupe n’a pas changé. Si j’avais souhaité te rendre propriétaire de tous les fichiers et dossiers inclus dans scripts/ j’aurai ajouté un -R pour appliquer le changement de façon récursive.

antoine@dressing:~$ sudo chown -R toi ~/scripts
antoine@dressing:~$ ls -l scripts/
-rwxr-xr-x 1 toi     antoine 3213 21 juin   2024 gitpullerdemo.sh
-rwxr-xr-x 1 toi     antoine 3222 24 juin   2024 gitpuller.sh
-rw-r--r-- 1 toi     antoine   68  3 janv. 18:37 thomasjefferson.txt

Ca t’aurais également rendu proprio du dossier en lui même. Mais j’aurai aussi pu suffixer /*, les droits ne se seraient cependant pas propagés au contenu des sous dossiers.

antoine@dressing:~$ sudo chown toi scripts/*

Tu peux également souhaiter modifier le groupe en même temps que le propriétaire, pour cela ajoute simplement deux points et le nom du groupe après le nom du propriétaire ; ou même juste le groupe et dans ce cas tu ne mentionne pas le propriétaire.

# Propriétaire et groupe
antoine@dressing:~$ sudo chown toi:toi scripts/gitpuller.sh

# Groupe seulement
antoine@dressing:~$ sudo chown :toi scripts/gitpuller.sh

Mais pour changer de groupe, il existe également la commande dédiée chgrp change group (qui prend aussi l’argument -R).

antoine@dressing:~$ sudo chgrp antoine scripts/gitpuller.sh

On a vu mes groupes un peu plus haut, avec la commande id, mon groupe principal est celui lié à mon utilisateur mais j’en ai d’autres (le groupe users et bluetooth). Tous les fichiers que je créé n’hériteront que de mon groupe principal.

antoine@dressing:~$ id
uid=1000(antoine) gid=1000(antoine) groupes=1000(antoine),100(users),110(bluetooth)
antoine@dressing:~$ touch scripts/ton_script.sh
antoine@dressing:~$ ls -l scripts/ton_script.sh
-rw-r--r-- 1 antoine antoine 0  8 janv. 19:49 scripts/ton_script.sh

Si je veux partager des fichiers avec plusieurs utilisateurs d’un groupe, je vais changer le groupe d’un dossier.

antoine@dressing:~$ mkdir shared_scripts
antoine@dressing:~$ sudo chgrp mes_potes shared_scripts
antoine@dressing:~$ ls -l
total 4
drwxr-xr-x 2 antoine mes_potes 4096  8 janv. 22:12 shared_scripts
antoine@dressing:~$ touch shared_scripts/quadrature_du_cercle.sh
antoine@dressing:~$ ls -l ~/shared_scripts/
total 0
-rw-r--r-- 1 antoine antoine 0  8 janv. 22:18 quadrature_du_cercle.sh

Le fichier nouvellement créé n’hérite pas du groupe mes_potes. Pour cela, on va utiliser un sticky-bit ; ça permet d’outrepasser le fonctionnement par défaut qui affecte mon utilisateur et mon groupe principal à un nouveau fichier.

Le sticky-bit peut être employé au niveau de l’utilisateur, du groupe ou, de autre. Il apparaît dans les permissions. Par défaut, la permission d’ouvrir un dossier correspond à la permission x. Lorsqu’un sticky-bit est utilisé x est remplacé par s. Dès lors chaque nouveau fichier héritera du groupe du dossier.

antoine@dressing:~$ sudo chmod g+s ~/shared_scripts
antoine@dressing:~$ ls -l
total 4
drwxr-sr-x 2 antoine mes_potes 4096  8 janv. 22:18 shared_scripts

# Note bien le "s"

antoine@dressing:~$ touch shared_scripts/conjecture_goldbach.sh
antoine@dressing:~$ ls -l ~/shared_scripts/
total 0
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:28 conjecture_goldbach.sh
-rw-r--r-- 1 antoine antoine   0  8 janv. 22:18 quadrature_du_cercle.sh

Tu dois remarquer que le fichier déjà existant n’a pas été impacté mais que le nouveau fichier a bien hérité du groupe du dossier. Et il se passe le même phénomène selon que tu copies ou déplace un fichier (la copie créée un nouveau fichier, le déplacement non).

antoine@dressing:~$ touch conjecture_syracuse.sh # Muraille de Chine
antoine@dressing:~$ cp conjecture_syracuse.sh shared_scripts/ # La copie créée un nouveau fichier
antoine@dressing:~$ touch loterie_montyhall.sh
antoine@dressing:~$ mv loterie_montyhall.sh shared_scripts/ # Le déplacement non !
antoine@dressing:~$ ls -l shared_scripts/
total 0
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:28 conjecture_goldbach.sh
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:31 conjecture_syracuse.sh
-rw-r--r-- 1 antoine antoine   0  8 janv. 22:32 loterie_montyhall.sh
-rw-r--r-- 1 antoine antoine   0  8 janv. 22:18 quadrature_du_cercle.sh

Permissions de fichiers basées sur POSIX

POSIX est un standard qui est utilisé dans Unix comme dans Linux afin de permettre une certaine compatibilité. Initialement, les permissions étaient définies de manière numérique mais de nos jours elles sont affichées par des symboles r pour read, la permission de lecture, w pour write, écriture et, x execute, exécuter. Ces permissions s’appliquant au propriétaire, au groupe et, à toute autre entité, elles sont représentées par groupe de trois caractères lors que l’on utilise ls au format long avec une exception : le premier caractère permet de définir s’il s’agit d’un dossier d ou d’un fichier -.

La présence d’une permission est représentée par la lettre correspondante rwx ou par l’absence de cette lettre au profit d’un -. Par exemple, un fichier que le propriétaire peut lire, modifier, et exécuter, que le groupe et other peut uniquement lire présentera les permissions suivantes : -rwxr--r--. Exactement comme les scripts du dossier shared_scripts de la partie précédente.

La représentation par les lettres est assez rapide à prendre en main du moment que tu te souviens de l’application des permissions u, g, o -> user, group, other. Par contre au format numérique, c’est un tout petit peu plus complexe. Mais si tu as déjà fait un changement de base binaire vers décimal ça devrait bien se passer (un petit calcul de masque à la main ?).

J’ai franchement la flemme d’animer d’autres cas (c’est vraiment fait de manière artisanale) alors pour t’aider, tu pourras utiliser le calculateur de permissions de Vic Demuzere. Dis toi juste que si c’est un - le bit est à zéro et que si y a la lettre le bit est à un.

Au même titre qu’on l’a utilisé pour ajouter un sticky-bit au dossier shared_scripts, tu utiliseras chmod pour modifier les permissions des fichiers et dossiers aux niveaux User, Group et, Other. Tu peux ajouter par exemple la permission d’écriture au groupe chmod g+w, ou retirer la permission de lire à other chmod o-r ou bien remplacer l’existant et combiner chmod u=rwx,g=r,o=r. Mais disons plutôt que tu souhaites enlever toutes les permissions à qui que ce soit à part toi à la loterie_montyhall.sh.

antoine@dressing:~$ ls -l shared_scripts/ # Rappel des droits
total 0
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:28 conjecture_goldbach.sh
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:31 conjecture_syracuse.sh
-rw-r--r-- 1 antoine antoine   0  8 janv. 22:32 loterie_montyhall.sh
-rw-r--r-- 1 antoine antoine   0  8 janv. 22:18 quadrature_du_cercle.sh
antoine@dressing:~$ chmod g-r,o-r loterie_montyhall.sh
antoine@dressing:~$ ls -l shared_scripts/
total 0
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:28 conjecture_goldbach.sh
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:31 conjecture_syracuse.sh
-rw------- 1 antoine antoine   0  8 janv. 22:32 loterie_montyhall.sh
-rw-r--r-- 1 antoine antoine   0  8 janv. 22:18 quadrature_du_cercle.sh

Si tu peux combiner les permissions, pourquoi tu gênerais pour combiner également les entités auxquelles tu les applique ?! Allez hop, on remet les permissions de lecture à group et other d’un seul coup. C’est pas grand chose mais c’est tout de même puissant, non ?

antoine@dressing:~$ chmod go=r shared_scripts/loterie_montyhall.sh
antoine@dressing:~$ ls -l shared_scripts/
total 0
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:28 conjecture_goldbach.sh
-rw-r--r-- 1 antoine mes_potes 0  8 janv. 22:31 conjecture_syracuse.sh
-rw-r--r-- 1 antoine antoine   0  8 janv. 22:32 loterie_montyhall.sh
-rw-r--r-- 1 antoine antoine   0  8 janv. 22:18 quadrature_du_cercle.sh

Je t’ai déjà dit que les fichiers d’un dossier héritaient des permissions du dossier parent mais tu pourrais te demander d’où proviennent les permissions par défaut. C’est vraiment propre à chaque distribution mais c’est définit par umask.

Un umask est définit de façon numérique comme les droits chmod mais les valeurs sont inversées par rapport à celle de chmod. Si la valeur 7 d’un chmod représente « tous les droits », 7 dans un umask représente « aucun droit ». Modifier un umask est une opération lourde de conséquences donc arme-toi du manuel (man umask) si tu dois le faire mais surtout, ce n’est pas opération fréquente, elle change le comportement par défaut du système de fichier donc elle peut créer des problématiques si quelqu’un qui n’est pas bien (in)formé intervient sur le système et peut aller jusqu’à entraîner un problème de sécurité en exposant trop de fichiers à un attaquant.

Permissions basées sur des ACL

Les permissions POSIX sont limitées à un utilisateur et un groupe ou toute autre entité. Mais ne permettent pas de spécifier des droits pour plusieurs. Pour faire ça, on fait appel aux ACL (Access Control List), parfois nommées FACL (Filesystem Access Control List).

Les ACL et les outils pour les définir fonctionnent de la même manière sur toutes les distributions MAIS, elles ne sont pas actives sur toutes les distributions. Le support des ACL est défini au montage de la partition.

Afin de t’assurer que le support des ACL soit activé sur ta partition, il faut regarder la manière dont elle est montée. Pour cela, regarde dans la table de systèmes de fichiers `fstab`.

root@dressing:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=305806a9-4e9d-4844-b3e8-702d6549ce5e /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda1 during installation
UUID=2f641569-e15b-43db-ac82-7ee8639b36ed none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Ce doit être définit dans les options de montage… sauf que là non ! Aucune trace de la mention acl chez moi ; juste errors=remount-ro 0. Et pour cause, sous Debian Bookworm les ACL sont actives par défaut. Le système de fichier de /dev/sda2 où réside la / étant ext4 on va utiliser tune2fs pour regarder les options de montage par défaut.

root@dressing:~$ tune2fs -l /dev/sda2 | grep "mount options"
Default mount options:    user_xattr acl

Si tu ne trouve mention d’acl ni dans ton fstab ni dans les options par défaut de montage de ton installation, il est probable qu’elles ne soient pas activées.

Les noms des outils pour travailler avec les ACL sont faciles à retenir, on va pouvoir les paramétrer avec setfacl et les afficher avec getfacl.

Bien que setfacl utilise une syntaxe proche de celle de chmod pour la définition des permissions, la syntaxe pour définir le type d’interaction (supprimer, écraser, modifier) est différente :

• setfacl -m : modifier
• setfacl -x : supprimer
• setfacl -s : remplacer

Pour savoir si des ACL sont définies ce n’est pas compliqué, POSIX n’ayant pas de manière de les représenter, lors de l’affichage long du contenu d’un dossier un + apparaîtra après le dernier x (Execution pour Other ; t’as déjà vu beaucoup de fois mes ls -l, je te le remets pas tant que j’aurai pas défini d’ACL).
Mettons que je souhaite donner accès à l’utilisateur toi à la conjecture de Syracuse.

antoine@dressing:~/shared_scripts$ setfacl -m u:toi:rw conjecture_syracuse.sh
bash: setfacl : commande introuvable

Les ACL sont supportées par défaut sous Debian mais les outils de gestion ne sont pas installés. Ne pas paniquer…

antoine@dressing:~/shared_scripts$ apt search acl | head

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

En train de trier…
Recherche en texte intégral…
acl/stable,now 2.3.1-3 amd64
  liste de contrôle d'accès – utilitaires

root@dressing:~# apt install acl # Ok, on y revient...

antoine@dressing:~/shared_scripts$ setfacl -m u:toi:rw conjecture_syracuse.sh
antoine@dressing:~/shared_scripts$ ls -l
total 0
-rw-r--r--  1 antoine mes_potes 0  8 janv. 22:28 conjecture_goldbach.sh
-rw-rw-r--+ 1 antoine mes_potes 0  8 janv. 22:31 conjecture_syracuse.sh
-rw-r--r--  1 antoine antoine   0  8 janv. 22:32 loterie_montyhall.sh
-rw-r--r--  1 antoine antoine   0  8 janv. 22:18 quadrature_du_cercle.sh
antoine@dressing:~/shared_scripts$ getfacl conjecture_syracuse.sh 
# file: conjecture_syracuse.sh
# owner: antoine
# group: mes_potes
user::rw-
user:toi:rw-
group::r--
mask::rw-
other::r--

Et tu peux ajouter autant que tu le souhaites, avec des utilisateurs, des groupes ou même, other. Tu remplaces alors le u par g ou o…

antoine@dressing:~/shared_scripts$ setfacl -m g:la_famille:rwx conjecture_syracuse.sh
antoine@dressing:~/shared_scripts$ setfacl -m g:les_amis:rw conjecture_syracuse.sh
antoine@dressing:~/shared_scripts$ getfacl conjecture_syracuse.sh 
# file: conjecture_syracuse.sh
# owner: antoine
# group: mes_potes
user::rw-
user:toi:rw-
group::r--
group:la_famille:rwx
group:les_amis:rw-
mask::rw-
other::r--

# Je ne l'ai pas fait pour de vrai. C'est juste un exemple...

Ca fonctionne à peu près de la même manière sur un dossier à l’exception que tu pourras gérer l’héritage tant qu’à faire. Pour cela, je vais préfixer la modification d’un d: afin d’indiquer que ce sera la permission par défaut. Du coup, tout nouveau fichier créé héritera des ACL du dossier.

antoine@dressing:~$ sudo chown :antoine shared_scripts # Je remets en codition initiale
antoine@dressing:~$ setfacl -m d:g:mes_potes:rw shared_scripts
antoine@dressing:~$ getfacl shared_scripts
# file: shared_scripts
# owner: antoine
# group: antoine
user::rwx
group::r-x
group:mes_potes:rw-
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:mes_potes:rw-
default:mask::rwx
default:other::r-x

antoine@dressing:~$ touch shared_scripts/trisection_angle.sh
antoine@dressing:~$ ls -l shared_scripts/
total 0
-rw-r--r--  1 antoine mes_potes 0  8 janv. 22:28 conjecture_goldbach.sh
-rw-rw-r--+ 1 antoine mes_potes 0  8 janv. 22:31 conjecture_syracuse.sh
-rw-r--r--  1 antoine antoine   0  8 janv. 22:32 loterie_montyhall.sh
-rw-r--r--  1 antoine antoine   0  8 janv. 22:18 quadrature_du_cercle.sh
-rw-rw-r--+ 1 antoine antoine   0 13 janv. 22:49 trisection_angle.sh
antoine@dressing:~$ getfacl shared_scripts/trisection_angle.sh
# file: shared_scripts/trisection_angle.sh
# owner: antoine
# group: antoine
user::rw-
group::r-x                      #effective:r--
group:mes_potes:rw-
mask::rw-
other::r--

Les fichiers existant du dossier n’héritent pas par défaut des ACL.

Dans cet article, j’ai appris l’existence de type, ça peut être utile dans certains cas ; J’ai d’avantage compris la notion de lien physique parce que c’était ésotérique pour moi et, J’ai également appris le sticky-bit que je ne connaissais pas du tout. Enfin, j’avais déjà suivi la mise en oeuvre des ACL avec un collègue (DDC) et ça me permet de revoir ce sujet et de le rendre un peu moins effrayant. Je pense que les cases à cocher sous Windows étaient plus rassurantes.