Tab+complétion nom de fichier+sudo+droits

Support Debian
#1

bonjour ,

j’aimerais avoir un avis sur mon interprétation d’une erreur que j’ai commise sans en comprendre l’origine à propos de la lecture de /root/.selected_editor = comme la complétion ( avec sudo cat … ) du nom de ce fichier ne fonctionnait pas j’en avais déduit qu’il n’existait pas , et pourtant en utilisant un terminal root je l’ai bien trouvé .

  • hypothèse de départ que je faisais jusqu’à ce matin : si la complétion du nom d’un fichier n’aboutit pas c’est que le fichier n’existe pas . Avec l’utilisation très fréquente que je fais de sudo je viens d’en voir une limite : il faut penser aux droits
mm@Xfce:~$ sudo ls -l /root/.selected_editor
-rw-r--r-- 1 root root 75 14 févr. 01:35 /root/.selected_editor

root@Xfce:~# cat .se(lected_editor) ---> completion  OK
mm@Xfce:~$ sudo cat /ro(ot/)  --->  completion OK 
mm@Xfce:~$ sudo cat /root/.se(   ) --->  la completion ne marche plus

apparemment les droits de lecture de l’utilisateur ne suffisent pas pour la complétion et comme la complétion dans un terminal root fonctionne il faut donc aussi les droits d’écriture . Est-ce correct ? C’est la question la plus importante .

Ensuite vient la question pourquoi ? Un lien vers une explication claire de "comment fonctionne la complétion avec Tab et sous linux " devrait suffire . Je vais essayer de trouver ça mais si une âme charitable était encline à me faciliter la tâche …

#2

Bonjour

mic@deb116:~$ ls -ld /root/
drwx------ 7 root root 4096 14 févr. 14:10 /root/
mic@deb116:~$

Les bits mode pour un répertoire :
r Lister le contenu du répertoire
w Créer et supprimer des fichiers dans le répertoire
x Accéder aux fichiers contenus dans le répertoire

Le propriétaire de ce répertoire est le compte root
Donc, seul le propriétaire (donc root) de ce répertoire a le droit
d’en lister le contenu, d’y créer/supprimer un fichier, et d’accéder aux fichiers qu’il contient.

Si la ligne de commandes est rédigée depuis le compte mm
la complétion ne sera exécutée qu’avec les privilèges du compte mm
qui n’a donc pas accès au contenu du répertoire /root/
et donc ne peut pas savoir quels fichiers existeraient dans ce répertoire

Je te laisse appliquer le même raisonnement à la racine du système,
sachant que les bits mode de la racine sont :

mic@deb116:~$ ls -ld /
drwxr-xr-x 19 root root 4096 29 sept.  2014 /
mic@deb116:~$
#3

voilà donc la vraie raison du refus de complétion : j’étais sur la bonne voie mais je ne regardais pas là où il fallait = les droits associés au répertoire et non au fichier . Merci bien . De plus je viens d’apprendre une nouvelle option qui concerne les répertoires .

Tant qu’on est dans les répertoires , en abusant un peu :

mm@Xfce:~$ ls -ld /root
drwx------ 8 root root 4096 14 févr. 01:36 /root
mm@Xfce:~$ ls -ld /root/
drwx------ 8 root root 4096 14 févr. 01:36 /root/

je sais que /root = le home de root . Que désigne /root/ ? Je ne vois pas de différence même pour leur contenu:

root@Xfce:~# ls -a  ; ls -a /root/
.             .bash_aliases  .cache   .gnupg    .profile          .synaptic
..            .bash_history  .config  .lesshst  .selected_editor  .vim
20-intel.com  .bashrc        file     .local    sudo              .viminfo
.             .bash_aliases  .cache   .gnupg    .profile          .synaptic
..            .bash_history  .config  .lesshst  .selected_editor  .vim
20-intel.com  .bashrc        file     .local    sudo              .viminfo
#4

Dans le cas que tu présentes, il n’y a pas de différence,
mais dans certains cas :

mic@deb116:~$ ls -l ~/partage
lrwxrwxrwx 1 root root 23  5 janv. 13:28 /home/mic/partage -> /donnees/michel/partage
mic@deb116:~$

Ci-dessus, on voit que le nom de fichier listé est un fichier de type lien (voir la lettre l au début de ligne retournée) et que ce fichier est lié au fichier nommé /donnees/michel/partage

mic@deb116:~$ ls -ld ~/partage
lrwxrwxrwx 1 root root 23  5 janv. 13:28 /home/mic/partage -> /donnees/michel/partage
mic@deb116:~$

Ci-dessus, même si j’ai utilisé l’option d, le retour est exactement le même que précédement.

mic@deb116:~$ ls -ld ~/partage/
drwxr-xr-t 2 mic mic 4096 20 déc.   2021 /home/mic/partage/
mic@deb116:~$

Ci-dessus, j’ai ajouté un / à la fin du nom à lister
et on voit que le retour n’est plus du tout le même :
les bits mode, la date/heure, etc. ne sont plus les mêmes
car ce ne sont plus les ceux du lien, mais du fichier lié
et ce fichier lié est d’ailleurs un fichier de type répertoire
vu la première lettre retournée qui est un d

mic@deb116:~$ ls -l ~/partage/
total 4
-rw-r--r-- 1 mic mic 88  6 janv.  2022 monFichierPartagé
mic@deb116:~$

Ci-dessus, on voit le contenu du répertoire lié
alors que sans le / à la fin du nom, comme dans la première ligne de commande donnée dans ces exemples, on ne verrait que le nom du lien .

Voici les deux lignes de commande l’une après l’autre,
avec pour seule différence, ce caractère / en plus à la fin du nom

mic@deb116:~$ ls -l ~/partage
lrwxrwxrwx 1 root root 23  5 janv. 13:28 /home/mic/partage -> /donnees/michel/partage
mic@deb116:~$ 

mic@deb116:~$ ls -l ~/partage/
total 4
-rw-r--r-- 1 mic mic 88  6 janv.  2022 monFichierPartagé
mic@deb116:~$
#5

Non, je n’ai pas dit ls -l /dev/fd , mais ls -l /dev/fd/ . /dev/fd est un lien symbolique […] vers un répertoire, si tu ne mets pas le / final, ls va penser que tu peux voir le lien symbolique et non pas le contenu du répertoire ciblé.

c’était la remarque de @Almtesh suite à une erreur que j’avais faite et qui concernait l’oubli de cette barre oblique . Je ne m’en suis souvenu que suite à ta remarque ci-dessus . Avec un peu de chance ça restera .

en tout cas merci pour tous ces commentaires très clairs .

#6

C’est pas compliqué :

  1. le chemin d’un fichier peut contenir le caractère oblique «/».
  2. un nom de fichier ne peut pas contenir le caractère oblique «/».

Et c’est tout. :slight_smile:

#7

pas si sûr …
Je la trouve bien simpliste cette dernière affirmation …
Un chemin peut contenir (c’est presque un euphémisme) une barre oblique, voire plusieurs… OK,
Mais, un nom de fichier ne peut pas contenir de barre oblique ?? même en y apposant une contre oblique « \ » devant ou des guillemets, ou que sais-je… et justement j’en sais rien d’où je demande… :slightly_smiling_face:

#8

Oui c’est simpliste, mais c’est à remettre dans le contexte.

un nom de fichier ne peut pas contenir de barre oblique ??

En cherchant un peu, on obtient :

  • Windows (FAT32, NTFS): Any Unicode except NUL , \ , / , : , * , ? , " , < , > , | .
  • Mac(HFS, HFS+): Any valid Unicode except : or /
  • Linux(ext[2-4]): Any byte except NUL or /

Et même si c’était possible, l’utilisation d’un caractère oblique pour nommer un fichier ne serait qu’une mauvaise pratique.

même en y apposant une contre oblique « \ » devant ou des guillemets

Tu ne risques pas grand-chose à faire un test. :slight_smile:

#9

Par l’exemple:

  15/02/2023   11:32.48   /home/mobaxterm  touch test\/1
touch: test/1: Not a directory

  15/02/2023   11:33.01   /home/mobaxterm  touch "test/1"
touch: test/1: Not a directory

  15/02/2023   11:33.17   /home/mobaxterm  touch 'test/1'
touch: test/1: Not a directory

  15/02/2023   11:33.28   /home/mobaxterm 