Як дозволи на r - каталог працюватимуть у Linux?


11

Я створив створений каталог, має ці дозволи - інший користувач

drwxr - r-- 5 користувач користувачів 4096 сайтів 2012-09-15 19:30

Коли ls -l в каталозі як інший користувач

ls -l / home / user / сайти

це вихід каталогу. Я думав, що без встановленого біта x у цій директорії імена файлів взагалі не відображатимуться.

d????????? ? ? ? ?                ? dev.user.com  
-????????? ? ? ? ?                ? user.20120914_082804.sql.gz   
d????????? ? ? ? ?                ? shared  
-????????? ? ? ? ?                ? shared.tar.gz  
-????????? ? ? ? ?                ? www.20120914_083256.tar.gz
d????????? ? ? ? ?                ? www.user.com

Чи є тут якась непослідовність?

Відповіді:


16

xдає дозвіл на фактичне перебування в каталозі та доступ до файлів у каталозі, rдає вам дозвіл на перегляд вмісту каталогу.

Якщо ви змінили ситуацію, надавши директорії xбіт і видаливши rбіт, користувач міг би відкрити shared.tar.gz(за умови належних дозволів на сам файл), але тільки якщо він заздалегідь знав ім'я файлу, оскільки lsне зміг би перерахувати файли в каталозі .


1
Я перевірю це і повернуся до вас. Я завжди вважав цей аспект спільного використання файлів Linux заплутаним.
vfclists

Така поведінка не характерна лише для Linux; він датується найдавнішими днями UNIX - Linux, будучи сумісною з UNIX системою, працює таким чином - і записи Windows NT ACL мають аналогічні біти дозволів.

2

Таке тлумачення дозволів датується ранньою файловою системою Unix. На початку були лише файли. (Ну, і пристрої, і труби, і ... але я намагаюся тут розповісти історію, не будьте на 100% суворо точні; до того ж, це все справедливо для пристроїв і труб і всього іншого, тому що все є файлом, навіть довідники).

Каталоги - це лише файли, які використовує файлова система для зберігання метаданих, що описують дерево каталогів, та файли, які вони містять. Кожен файл у каталозі описувався простою структурою даних, яка містила місце для імені файлу (спочатку 14 символів, IIRC) разом із номером inode, де зберігалися дані, розміром файлу, часовими марками та словом дозволів . Кожен каталог починався з двох записів з ім'ям .і .., перший вказує на inode цього самого каталогу, а другий на inode його батьківського каталогу.

Слово дозволу містило дев'ять біт, щоб описати поводження з власником, іншими членами тієї ж групи та світом. Три біти для кожного прапора, чи може відповідний користувач читати, записувати чи виконувати файл. (Ви можете помітити, що в слові дозволів 16 біт, яке я ігнорую, є ще п’ять біт. Зрештою, вони отримали значення, але це не стосується цієї частини історії.) (Також ця інтерпретація дев'яти біти залишилися майже однаковими для всіх нащадків раннього Unix, включаючи Linux.)

Отже, якщо каталог справді є лише спеціальним файлом і описується записом у деякому каталозі, він, очевидно, також має біти дозволу, і ці біти, ймовірно, щось означають. Але питання в тому, що саме. Найпростіший спосіб присвоїти значення цим бітам - це не змінювати в першу чергу те, що вони означають. І це по суті те, що було зроблено.

Отже, біт читання означає, що користувач може сам читати каталог. Це класично надає читачеві доступ до імені файлу, часових позначок, розміру та номера inode даних кожного файлу. Зокрема, з rнабором ви можете використовувати lsдля перегляду імен усіх файлів у каталозі, але цього недостатньо для відкриття (або використання будь-яким способом) будь-якого з перерахованих файлів.

Біт виконання означає, що користувач може "виконати" каталог. Оскільки каталоги особливі, виконувати справді означає, що шукати запис за назвою та використовувати його. Це означає, що ви можете спробувати відкрити файли, якщо xце встановлено, але без них rви не можете виявити їх імена. Звичайно, дозволи до запитуваного файлу також впливають на доступ, тому навіть xу каталозі ви не зможете прочитати файл, якщо він також не пропонує вам r.

Біт запису означає, що користувач може записувати в каталог, але, природно, лише опосередковується самою файловою системою. Це означає, що за допомогою wнабору ви можете створювати нові файли в цьому каталозі або редагувати записи в існуючих файлах. Але без xнабору фактично не можна використовувати жодні файли, і без них rви також не можете їх побачити.

Оскільки складніші моделі ідентичності користувачів складалися в Unix та його нащадках, ці ж основні описи зуміли залишитись надзвичайно незмінними.

Коротше кажучи, rозначає, що ви можете бачити його вміст, xозначає, що ви можете використовувати його, і wозначає, що ви можете змінювати його навіть для каталогів.


Я припускаю, що ви можете пояснити mode_tщось трохи більше (наприклад, частина, де дозволи та тип файлу зберігаються в одному 32-
бітовому

1
Я активно користувач Unix і розробник ще в 80-х. Я не намагався розповісти повну історію про те, що є справжньою сьогодні настільки, наскільки це ставиться в історичний контекст, і висловлюю своє задоволення тим, що та сама загадка, з якою я стикався при першому навчанні Unix, може бути задана сьогодні, і відповісти по суті те саме пояснення я отримав від місцевих гуру приблизно в 1983 році. Чим більше речей змінюється, тим більше вони залишаються тими ж ....
RBerteig
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.