Зазвичай файлова система підтримує налаштування дозволів для кожного збереженого елемента зазвичай і директорій, які або надають, або забороняють можливість керувати елементами файлової системи. Ці права можуть дозволяти або забороняти користувачу виконувати операції над об’єктами файлової системи. Найчастіше права визначають доступ на основі певних функцій, таких як читання, запис, навігація каталогами та виконання, а також розподіляють доступ між різними користувачами та групами користувачів.
Однією з добре усталених технологій керування доступом є механізм, розроблений для Unix і пізніше стандартизований POSIX. Інша поширена технологія - це списки контролю доступу (ACL), які мають кілька варіантів реалізації у файлових системах, а один із варіантів також визначений POSIX. Оскільки POSIX описує як традиційну модель доступу, що походить з Unix, так і ACL, першу модель для ясності називають традиційними дозволами POSIX, хоча цей термін не є широко відомим.
Інтерфейс користувача, керований правами доступу, підлаштовує доступні функції залежно від прав, встановлених для елементів файлової системи. Наприклад, інтерфейс може приховувати пункти меню, виконання яких заборонене відповідно до прав доступу, встановлених для конкретного об’єкта.
Історія
CTSS Рання система розподілу часу: Compatible Time-Sharing System (CTSS) підтримувала багатокористувацький режим. Кожен обліковий запис користувача мав «номер проблеми» та «номер програміста».
Перша версія файлової системи CTSS підтримувала лише два режими «тільки для читання». Один режим користувач міг встановлювати самостійно, а інший можна було зняти лише за допомогою спеціальних карток редагування, поданих до обчислювального центру. Файли могли спільно використовуватися користувачами в межах одного проєкту; у такому разі спільні файли отримували номер програміста нуль. Окрім бітів «тільки для читання», механізмів захисту не було.
Друга версія файлової системи містила окремі біти дозволів для режимів «тільки читання» та «тільки запис»; останній дозволяв лише додавання інформації у кінець файлу. Також було введено біт «приватності», який дозволяв доступ до файлу тільки його автору, та біт «захисту», який дозволяв лише автору змінювати дозволи файлу.
Multics Користувачі системи розподілу часу Multics мають Person_id, а проєкти - Project_id. Вхід у систему здійснюється за поєднанням цих двох ідентифікаторів. Файл містить список контролю доступу (ACL), записи якого можуть містити Person_id або *, Project_id або *, а також мітку екземпляра (instance tag) або *. Мітка екземпляра визначає тип доступу; наприклад, символ “a” позначає процес зі звичайної інтерактивної сесії. Запис ACL порівнюється з Person_id, Project_id та міткою екземпляра процесу. Символ * є шаблоном, що відповідає будь-якому значенню. Використовується той запис ACL, що має найменшу кількість шаблонів.
У файлах ACL забезпечували дозволи читання, запису та виконання. Для каталогів вони містили додаткові режими: status (читання атрибутів файлів і каталогів); modify (зміну атрибутів та видалення записів каталогу); append (додавання нових елементів).
TENEX Користувач у TENEX належить до певної групи.
Файли та каталоги мали набір бітів доступу: шість бітів для власника, шість — для інших користувачів у групі та шість — для всіх інших. Для файлів ці біти означали можливість читання, запису, виконання та додавання, причому шостий біт не використовувався.
Для каталогів біти дозволяли або забороняли доступ до каталогу; визначали, чи можна відкривати файли в каталозі залежно від їхніх власних дозволів; чи можуть виконуватися операції, подібні до функцій власника; а також чи дозволено додавати нові файли до каталогу. П’ятий і шостий біти також залишалися невикористаними.
TOPS-10 Обліковий запис користувача в TOPS-10 має номер програміста та номер проекту.
Файли містять набір бітів доступу: три біти для власника, три — для інших користувачів з тим самим номером проєкту та три — для всіх інших.
Операційна система може трактувати будь-який обліковий запис із номером програміста, який збігається з номером програміста каталогу, як власника файлів у цьому каталозі. Або, залежно від налаштувань, будь-який обліковий запис з відповідним номером програміста та номером проєкту також розглядається як власник. Значення бітів доступу у TOPS-10 узгоджуються з моделлю дозволів, що пізніше використовується у Unix-подібних системах.
Значення бітів доступу мають такі трактування:
7 — відсутність будь-яких прав доступу, за винятком можливості власника переглянути файл, щоб змінити його дозволи. 6 — лише виконання. 5 — читання та виконання. 4 — додавання (append), читання та виконання. 3 — оновлення (update), додавання, читання та виконання. 2 — запис, оновлення, додавання, читання та виконання. 1 — перейменування, запис, оновлення, додавання, читання та виконання. 0 — змінення дозволів, перейменування, запис, оновлення, додавання, читання та виконання. Власник файлу завжди має право змінювати дозволи.
Власник завжди має право змінювати дозволи.
UNIX та Unix-подібні системи Файли в першому виданні Unix (v1) мали п'ять біт дозволів:
write, non-owner; read, non-owner; write, owner; read, owner; executable;
та set-UID bit. У ньому не було поняття груп. Це тривало до третього видання (v3); четверте видання (v4) ввело групи, і файли у v4 мали дев'ять бітів прав доступу:
читай, власнику; пиши, власнику; виконати, власник; читати, групувати; писати, групувати; виконати, згрупувати; читати, інше; писати, інше; виконати, інший;
а також біти set-UID та set-GID; Це той самий набір дозволів, що вказані в POSIX та надаються сучасними Unix та Unix-подібними системами.
Приклади Реалізація прав доступу у файлових системах може суттєво відрізнятися. Нижче наведено кілька характерних прикладів.
NTFS, яка використовується в багатьох версіях Windows, включно з сучасними, застосовує списки контролю доступу (ACL) для керування правами. ACL у NTFS вважаються потужним, але досить складним механізмом.
Файлові системи Linux, такі як ext2, ext3, ext4 та Btrfs, підтримують як традиційні дозволи POSIX, так і ACL стандарту POSIX.1e. Для файлових систем ext3 і ext4 також існує експериментальна підтримка ACL формату NFSv4.
FreeBSD підтримує ACL POSIX.1e на файловій системі UFS, а також ACL формату NFSv4 для UFS і ZFS.
Файлові системи HFS та HFS+, реалізовані в класичних операційних системах Mac OS, не підтримують дозволів.
macOS підтримує дозволи, сумісні з POSIX, у файлових системах HFS+ і APFS. Починаючи з версії 10.4 (“Tiger”), система також підтримує ACL формату NFSv4 поряд із традиційними дозволами POSIX. Посібник з адміністрування Apple Mac OS X Server 10.4+ File Services рекомендує за можливості використовувати лише традиційні дозволи Unix. Класичні версії Mac OS також підтримують атрибути “Protected”/“Locked”, які відповідають прапорцю user immutable у полі прапорців файлової системи 4.4BSD.
Оригінальна файлова система File Allocation Table (FAT) містить атрибут “тільки читання”, який застосовується до файлу для всіх користувачів.
Операційна система OpenVMS визначає чотири основні функції доступу — читання, запис, виконання та видалення — і чотири категорії користувачів: system, owner, group і world. Набір дозволів також може включати розширення, серед яких додаткова дія delete та додатковий клас system. ACL підтримуються у версіях VMS 4.0 і новіших.
У Solaris підтримка ACL залежить від файлової системи: UFS реалізує ACL POSIX.1e, тоді як ZFS підтримує лише ACL формату NFSv4.
IBM z/OS реалізує захист файлової системи за допомогою механізму RACF (Resource Access Control Facility).
Файлова система AmigaOS забезпечує досить розвинену модель дозволів, незвичну для одно користувацьких операційних систем. У версіях AmigaOS 1.x дозволи охоплюють операції Archive, Read, Write, Execute та Delete (разом позначаються як ARWED). У версіях AmigaOS 2.x і новіших додано додаткові атрибути Hold, Script і Pure.
Операційні системи OpenHarmony та openEuler, а також Linux-орієнтована версія openEuler server OS, застосовують розподілену файлову систему Harmony Distributed File System (HMDFS), яка використовує контроль доступу на основі маркерів (token-based access control) та забезпечує можливості керування дозволами, подібні до POSIX. Виключенням є OpenEuler, де частина можливостей реалізована інакше.
Традиційні дозволи POSIX Традиційно права доступу у файлових системах на основі Unix визначаються стандартом POSIX.1. Він встановлює три класи користувачів — власник, група та інші — для яких можуть бути дозволені або заборонені три основні операції: читання, запис і виконання. Під час створення файлу його дозволи за замовчуванням визначаються маскою umask, яка встановлює, які біти доступу мають бути вимкнені.
У файловій системі Unix майже все розглядається як файл, включно з каталогами та спеціальними файлами.
Класи Класи визначають, яким користувачам застосовуються дозволи.
Клас власника стосується користувача, який є власником файлу. Клас групи стосується користувачів, що входять до групи власника файлу. Клас інших застосовується до всіх інших користувачів.
Ефективні дозволи — це дозволи того класу, до якого користувач належить у першу чергу. Наприклад, користувач-власник має дозволи класу власника, навіть якщо він одночасно входить до групи.
Дозволи Наведені нижче дозволи визначають, які операції можна виконувати над файлами й каталогами.
Читання (r)
Для файлів: дає змогу читати вміст файлу (але не його назву чи метадані, які визначаються дозволами батьківського каталогу). Для каталогів: дає змогу переглядати назви файлів і підкаталогів, але не їхні метадані (inode). Для доступу до вмісту потрібен дозвіл на виконання каталогу.
Запис (w)
Для файлів: дозволяє змінювати вміст файлу. Для каталогів: дозволяє створювати, перейменовувати та видаляти файли всередині каталогу. Для виконання цих дій також потрібен дозвіл на виконання каталогу, оскільки без нього каталог не може бути відкритий.
Для файлів: надає можливість виконувати файл. Цей дозвіл необхідно встановити для виконуваних програм, щоб дозволити їх запуск. Для каталогів: дозволяє отримувати доступ до метаданих елементів усередині каталогу (за умови, що відома їхня назва). Без дозволу на виконання каталог не можна "відкрити", навіть якщо дозволено читання.
Загальні вимоги до доступу всередині каталогів Для доступу до файлу всередині каталогу потрібно:
Знати назву файлу (що можливо, якщо встановлено дозвіл на читання каталогу або якщо назву вгадано). Мати дозвіл на виконання каталогу, щоб отримати доступ до його inode. Мати відповідний дозвіл на читання, запис або виконання самого файлу.
Зведені правила вимог до операцій Щоб прочитати файл, потрібно:
Дозвіл на читання файлу. Дозвіл на виконання батьківського каталогу.
Щоб записати файл, потрібно:
Дозвіл на запис файлу. Дозвіл на виконання батьківського каталогу.
Щоб виконати файл, потрібно:
Дозвіл на читання та виконання файлу. Дозвіл на виконання батьківського каталогу.
Щоб дізнатися назву потрібного файлу:
Дозвіл на читання батьківського каталогу.
Щоб додати, видалити або перейменувати файл, потрібно:
дозволи на запис та виконання в батьківському каталозі.
Нотатки Метадані файлу або каталогу зазвичай включають ідентифікатор inode, тип файлу, розмір, власника (UID, GID) та біти дозволів.
Зміна дозволів каталогу, на відміну від файлу, є однією з найбільш неправильно трактованих особливостей файлових систем: дозволи каталогу впливають на доступ до елементів, що в ньому містяться.
На відміну від ACL, дозволи POSIX не успадковуються. Файли, створені в каталозі, не обов’язково повторюють дозволи, встановлені для каталогу.
Зміна поведінки дозволів за допомогою бітів setuid, setgid та sticky До кожного файлу можуть застосовуватися три додаткові однобітові атрибути, пов’язані з дозволами та збережені у файловому режимі разом із звичайними бітами доступу.