$ chmod u=rwx, g=rx, o=r *
Значення прав доступу різне для різних типів файлів. Для файлів операції, які можна робити, випливають із самих назв прав доступу. Наприклад, щоб переглянути вміст файлу командою cat(l), користувач повинний мати право на читання (г). Редагування файлу, тобто його зміна, передбачає наявність права на запис (w). Нарешті, для того щоб запустити деяку програму на виконання, потрібно мати відповідне право (х). Файл, що виконується, може бути як скомпільованою програмою, так і скриптом командного інтерпретатора shell. В останньому випадку також знадобиться право на читання, оскільки при виконанні скрипта командний інтерпретатор повинний мати можливість зчитувати команди з файлу. Усе сказане, за винятком, мабуть, права на виконання, що має зміст лише для звичайних файлів і каталогів, справедливо і для інших типів файлів: спеціальних файлів пристроїв, іменованих каналів, і сокетов. Наприклад, щоб мати можливість роздрукувати документ, потрібно мати право на запис у спеціальний файл пристрою, зв'язаний із принтером. Для каталогів ці права мають інший зміст, а для символічних зв'язків вони взагалі не використовується, оскільки контролюються цільовим файлом.
Права доступу для каталогів не настільки очевидні. Це, у першу чергу, зв'язане з тим, що система трактує операції читання і запису для каталогів відмінно від інших файлів. Право читання каталогу дозволяє одержати імена (і тільки імена) файлів, що знаходяться в даному каталозі. Щоб одержати додаткову інформацію про файли каталогу (наприклад, докладний лістинг команди Is -/), системі прийдеться "заглянути" у метадані файлів, що вимагає права на виконання для каталогу. Право на виконання також буде потрібно для каталогу, у який ви захочете перейти (тобто зробити його поточним) за допомогою команди cd (1). Це ж право потрібно мати для доступу до всіх каталогів на шляху до зазначеного. Наприклад, якщо ви установите право на виконання для всіх користувачів в одному зі своїх підкаталогів, він усе рівно залишиться недоступним, поки ваш домашній каталог не буде мати такого ж права.
Права г и х діють незалежно, право х для каталогу не вимагає наявності права м, і навпаки. Комбінацією цих двох прав можна домогтися цікавих ефектів, наприклад, створення "темних" каталогів, файли яких доступні тільки у випадку, якщо користувач заздалегідь знає їхні імена, оскільки одержання списку файлів таких каталогів заборонено. Даний прийом, до речі, використовується при створенні загальнодоступних архівів у мережі (FTP-серверів), коли деякі розділи архіву можуть використовуватися тільки тими, хто знає про наявність того чи іншого файлу в каталозі. Приведемо приклад створення "темного" каталогу.
$ pwd Де ми знаходимося?
home/andrei
$ mkdir darkroom Створимо каталог
$ Is — 1 Одержимо його атрибути
-rwxr--r-- 2 andy group 65 Dec 22 19:13 darkroom
$ chaod a-r+x darkroom Перетворимо його в "темний"каталог
$ Is - 1 Одержимо його атрибути
--wx--x--x 2 andy group 65 Dec 22 19:13 darkroom
$ cp filel darkroom Помістимо в каталог darkroom деякий файл
$ cd darkroom Перейдемо в цей каталог
$ Is -I darkroom Спробуємо одержати лістинг каталогу
-#permi3sion denied На жаль...
$ cat filel Проте, заздалегідь знаючи ім'я файлу (filel), можна працювати з ним (наприклад, прочитати, якщо є відповідне право доступу)
Особливої уваги вимагає право на запис для каталогу. Створення і видалення файлів у каталозі вимагають зміни його вмісту, і, отже, права на запис у цей каталог. Найважливіше, що при цьому не враховуються права доступу для самого файлу. Тобто для того, щоб видалити деякий файл із каталогу, не обов'язково мати які-небудь права доступу до цього файлу, важливо лише мати право на запис для каталогу, у якому знаходиться цей файл. Майте на увазі, що право на запис у каталог дає великі повноваження, і надавати це право потрібно з обережністю. Правда, існує спосіб трохи убезпечити себе у випадку, коли необхідно надати право на запис іншим користувачам, — установка прапора Sticky bit на каталог.
У табл. 1.2 приведені приклади деяких дій над файлами і мінімальні права доступу, необхідні для виконання цих операцій.
Таблиця 1.2. Приклади прав доступу
| Команда | Зміст дії | Мінімальні права доступу | |
| для звичайного файлу | для каталогу, що містить файл | ||
| cd /u/andrei | Перейти в каталог /u/andrei | — | x |
| Is /u/andrei/* .с | Вивести усі файли із суффиксом з цього каталогу | — | г |
| Is -s /u/andrei/*.с | Вивести додаткову інформацію про ці файли (розмір) | —— | гх |
| cat report.txt | Вивести на екран вміст файлу report.txt | г | х |
| cat » report.txt | Додати дані у файл report.txt | W | х |
| runme.sh | Виконати програму runme | х | х |
| runme | Виконати скрипт командного інтерпретатора runme. Sh | гх | х |
| rm runme | Видалити файл runme у поточному каталозі | — | XW |
Отже, для виконання операції над файлом мають значення клас доступу, до якого належить користувач, і права доступу, установлені для цього класу. Оскільки для кожного класу встановлюються окремі права доступу, усього визначено 9 прав доступу, по 3 на кожен клас.
Операційна система робить перевірку прав доступу при створенні, відкритті (для читання або запису), запуску на виконання або видаленні файлу. При цьому виконуються наступні перевірки:
1. Якщо операція запитується суперкористувачем, доступ дозволяється. Ніяких додаткових перевірок не робиться. Це дозволяє адміністратору мати необмежений доступ до усієї файлової системи.
2. Якщо операція запитується власником файлу, то:
а) якщо необхідне право доступу визначене (наприклад, при операції читання файлу встановлене право на читання для власника-користувача даного файлу), доступ дозволяється,
б) в противному випадку доступ забороняється.
3. Якщо операція запитується користувачем, що є членом групи, що є власником файлу, то:
а) якщо необхідне право доступу визначене, доступ дозволяється,
б) в противному випадку доступ забороняється.
4. Якщо необхідне право доступу для інших користувачів (other) установлено, доступ дозволяється, у противному випадку доступ забороняється.
Система проводить перевірки в зазначеній послідовності. Наприклад, якщо користувач є власником файлу, то доступ визначається винятково з прав власника-користувача, права власники-групи не перевіряються, навіть якщо користувач є членом власника-групи. Щоб проілюструвати це, розглянемо наступне:
--—rw-r-- 2 andy group 65 Dec 22 19:13 filel
Навіть якщо користувач andy є членом групи group, він не зможе ні прочитати, ні змінити уміст файлу filel. У той же час всі інші члени цієї групи мають таку можливість. У даному випадку, власник файлу має найменші права доступу до нього. Зрозуміло, розглянута ситуація носить гіпотетичний характер, оскільки користувач andy у будь-який момент може змінити права доступу до даного файлу як для себе (власника), так і для групи, і всіх інших користувачів у системі.
Додаткові атрибути файлу
Ми розглянули основні атрибути, що керують доступом до файлу. Існує ще кілька атрибутів, що змінюють стандартне виконання різних операцій. Як і у випадку прав доступу, ці атрибути по-різному інтерпретуються для каталогів і інших типів файлів.
Додаткові атрибути також встановлюються утилітою chmod(l), але замість кодів 'г', 'w' чи 'х' використовуються коди з табл. 1.3. Наприклад, для установки атрибута SGID для файлу filel необхідно виконати команду
$ chmod g+s filel'.
У табл. 1.3 приведені додаткові атрибути для файлів, і показано, як вони інтерпретуються операційною системою.
| Таблиця 1.3. Додаткові атрибути для звичайних файлів | ||
| Код | Назва | Значення |
| t | Sticky bit | Зберегти образ виконуваного файлу в пам'яті після завершення виконання |
| S | Set UID, SUID | Установити UID процесу при виконанні |
| S | SetGID, SGID | Установити GID процесу при виконанні |
| 1 | Блокування | Установити обов'язкове блокування файлу |
Установка атрибута Sticky bit (справжня назва — save text mode) рідко використовується в сучасних версіях FREEBSD для файлів. У ранніх версіях цей атрибут застосовувався з метою зменшити час завантаження програм, що часто запускаються, (наприклад, редактора або командного інтерпретатора). Після завершення виконання задачі її образ (тобто код і дані) залишалися в пам'яті, тому наступні запуски цієї програми займали значно менше часу.
Атрибути (чи прапори) SUID і SGID дозволяють змінити права користувача при запуску на виконання файлу, що має ці атрибути. При цьому привілеї будуть змінені (зазвичай розширені) лише на час виконання і тільки у відношенні цієї програми.
Як правило програма, що запускається, дістає права доступу до системних ресурсів на основі прав доступу користувача, що запустив програму. Установка прапорів SUID і SGID змінює це правило, призначаючи права доступу виходячи з прав доступу власника файлу. Таким чином, запущений виконуваний файл, яким володіє суперкористувач, дістає необмежені права доступу до системних ресурсів, незалежно від того, хто його запустив. При цьому установка SUID приведе до спадкування прав власника-користувача файлу, а установка SGID — власника-групи.
Як приклад використання цієї властивості розглянемо утиліту passwd(l), що дозволяє користувачу змінити свій пароль. Очевидно, що зміна пароля повинна привести до зміни зміни певних системних файлів (файлу пароля /etc/passwd чи /etc/shadow,або бази даних користувачів, якщо використовується додатковий захист системи). Зрозуміло, що надання права на запис у ці файли всім користувачам системи є аж ніяк не кращим рішенням. Установка SUID для програми passwd(l) (точніше, на файл /usr/bin/passwd — файл утиліти, що виконується, passwd(l)) дозволяє добірно дозволити це протиріччя. Оскільки власником файлу /usr/bin/passwd є суперкористувач (його ім'я в системі — root), то хто б ні запустив утиліту passwd(l) на виконання, під час роботи даної програми він тимчасово дістає права суперкористувача, тобто може робити запис у системні файли, захищені від інших користувачів.