Справа в тому, що я завжди думав, що ці дозволи згортаються один на одного, починаючи з самого загального (інший -> група -> користувач).
Якби це було так, тоді "інші" дозволи застосовуватимуться до всіх.
Іншими словами, якщо o = rwx кого цікавить, що таке дозволи для групи та користувача?
Це відрізняється від попереднього речення. Тут ви маєте на увазі, що дозволи мають або зв'язані разом, наприклад, що користувачX має дозвіл на читання, якщо користувачевіXX користується файлом, і файл читається користувачем, або якщо група, якій належить userX, належить файлу, а файл - група -читабельна, або якщо файл можна прочитати іншим способом. Але це не так працює. Насправді o=rwxозначає, що rwxдозволи стосуються інших, але це нічого не говорить про сутності, які не є іншими.
По-перше, не має значення безпосередньо, до яких груп належить користувач. Ядро не має уявлення про користувачів, що належать до груп. Що підтримує ядро, це для кожного процесу ідентифікатор користувача ( ефективний UID ) та список ідентифікаторів групи (ефективний GID та додаткові GID). Групи визначаються під час входу, шляхом процесу входу - це процес входу, який читає групову базу даних (наприклад /etc/group). Ідентифікатори користувачів та групи успадковуються дочірніми процесами¹.
Коли процес намагається відкрити файл із традиційними дозволами Unix:
- Якщо користувачем файлу є ефективний UID процесу, то використовуються біти дозволу користувача.
- В іншому випадку, якщо група, що володіє файлом, є ефективним GID процесу або одним із додаткових ідентифікаторів групи, тоді використовуються біти дозволів групи.
- В іншому випадку використовуються інші біти дозволу.
Ніколи не використовується тільки один набір бітів rwx. Користувач має перевагу над групою, яка має перевагу над іншими. Коли є списки контролю доступу , алгоритм, описаний вище, узагальнюється:
- Якщо у файлі є ACL для ефективного UID процесу, він використовується для визначення, чи надано доступ.
- В іншому випадку, якщо у файлі є ACL для ефективного GID процесу або один із додаткових ідентифікаторів групи процесу, тоді використовуються біти дозволів групи.
- В іншому випадку використовуються інші біти дозволу.
Дивіться також Переважність ACLS, коли користувач належить до декількох груп, щоб отримати докладнішу інформацію про використання записів ACL, включаючи ефект маски.
Таким чином, -rw----r-- alice internsвказується файл, який може читати та писати Аліса, і який можуть читати всі інші користувачі, крім стажистів. Файл із дозволами та правом власності ----rwx--- alice internsє доступним лише для стажистів, окрім Аліси (чи вона стажистка, чи ні). Оскільки Аліса може закликати chmodзмінити дозволи, це не забезпечує ніякої безпеки; це крайня справа. У системах з ACL, узагальнений механізм дозволяє видаляти дозволи з певних користувачів або певних груп, що іноді корисно.
Використання одного набору бітів, а не або-ing всіх бітів для кожної дії (читання, запис, виконання) має ряд переваг:
- Це має корисний ефект, що дозволяє видаляти дозволи з набору користувачів або груп у системах з ACL. У системах без ACL дозволи можна видалити з однієї групи.
- Простіше реалізувати: перевірити один набір бітів, а не комбінувати кілька наборів бітів разом.
- Простіше проаналізувати дозволи файлу, оскільки бере участь менше операцій.
¹ Вони можуть змінитися , коли УИП або setgid процес виконується. Це не пов’язано з проблемою.