pourquoi est-ce que je peux voir le directory sans privilège "read"?

maintenant je suis user "lawrence.li", je peux voir le directory "lijunda" avec le privilège "lire"

entrer la description de l'image ici

mais maintenant je n'ai pas de privilège "read", pourquoi puis-je voir ce directory?

entrer la description de l'image ici

Je suis confus que quelle est la différence entre "r" et "-" (pas de privilège de lecture), quelqu'un peut-il me dire pourquoi? Merci beaucoup

Essayez ls -l /tmp/lijunda et tout ce que vous verrez est le nom des files à l'intérieur-vous ne pourrez pas ouvrir les files, ni même voir la taille du file, les permissions, etc. sur les files dans ce directory.

C'est parce que le directory lui-même ne contient que des noms de files et des numéros d'inode – c'est tout.

L'access en lecture aux noms de files est contrôlé par l'autorisation de lecture.

L'access aux inodes pointés par le directory est contrôlé par l'autorisation d'exécution, et non par l'autorisation de lecture. Les inodes contiennent tous les détails réels sur le file, tels que la taille du file, le propriétaire, les permissions, le time de la dernière modification et l'location physique des données binarys qui contient le contenu du file.

Pour afficher les noms des files dans le directory, vous devez disposer d'une autorisation de lecture sur le directory. Vous n'avez pas besoin d'exécuter ou d'écrire des permissions pour cela.

Pour afficher les détails des files dans le directory, par exemple pour afficher le contenu de l'inode, vous devez disposer des permissions d'exécution sur le directory. Les permissions de lecture sur le directory ne font aucune différence pour l'affichage des détails d'un file si vous connaissez déjà le nom du file.

Pour afficher les détails des files dont vous ne connaissez pas les noms , vous devez les lire et les exécuter.

Et enfin, pour voir le contenu d'un file, il vous faut:

  1. lire les permissions sur le file lui-même,
  2. exécuter des permissions sur le directory qui contient le file *, et
  3. au less l'un des droits de lecture sur le directory contenant le file OU la connaissance du nom du file par d'autres moyens.

Voir ci-dessous par exemple.

 $ whoami vagrant $ ls -l total 12 drwxrwx--x 2 pete pete 4096 Dec 24 08:51 execute_only drwxrwxr-x 2 pete pete 4096 Dec 24 08:52 read_and_execute drwxrwxr-- 2 pete pete 4096 Dec 24 08:52 read_only $ ls -l read_only/ ls: cannot access read_only/mysterious_file: Permission denied total 0 -????????? ? ? ? ? ? mysterious_file $ cat read_only/mysterious_file cat: read_only/mysterious_file: Permission denied $ ls -l execute_only/ ls: cannot open directory execute_only/: Permission denied $ ls -l execute_only/unicorn_file -rw-rw-r-- 1 pete pete 55 Dec 24 08:51 execute_only/unicorn_file $ cat execute_only/unicorn_file This file only exists for you if you know it's here ;) $ ls -l read_and_execute/ total 4 -rw-rw-r-- 1 pete pete 83 Dec 24 08:52 jack_sparrow $ cat read_and_execute/jack_sparrow "After the reading, you will be executed." "That's *Captain* Jack Sparrow to you!" $ 

* Vous avez également besoin d'exécuter des permissions sur tous les directorys parents jusqu'à la racine, en passant.

L'autorisation de lecture se réfère à la capacité de lire le contenu du file. La capacité de voir quels files / directory, vous devez supprimer les users exécuter l'autorisation sur le directory lui-même. Cela signifierait bien entendu que l'user ne pouvait plus voir de files / directorys dans ce directory.

Voir ce lien par exemple:

Autorisations de directory

La command chmod peut également être utilisée pour contrôler les permissions d'access pour les directorys. Dans la plupart des cas, le schéma d'permissions pour les directorys fonctionne de la même manière qu'avec les files. Cependant, l'autorisation d'exécution est utilisée d'une manière différente. Il fournit un contrôle pour l'access à la list des files et d'autres choses.

Edit: Il semblerait que je n'ai pas bien expliqué cela, car je voulais faire reference au directory parent ( tmp ) et non au directory lijunda . @Wildcard fait un travail beaucoup mieux (et plus en profondeur) en répondant à ceci dans leur réponse ici