Які зв’язки пов’язують маску ACL та стандартний дозвіл групи на файл?


17

Спочатку я створюю файл і перевіряю його стандартні дозволи та записи ACL:

$ touch file; ls -l file; getfacl file
-rw-r--r-- 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
other::r--

Потім я встановлюю маску ACL у файл і ще раз перевіряю, чи це стандартні дозволи та записи ACL:

$ setfacl -m mask:rwx file
$ ls -l file; getfacl file
-rw-rwxr--+ 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
mask::rwx
other::r--

Зверніть увагу, що поряд з ACL-маскою також змінився стандартний дозвіл групи на файл.

  1. Який зв’язок існує між маскою ACL та стандартним дозволом групи?
  2. Яка причина поєднання дозволів ACL-маски та дозволу групи файлів? Яка логіка лежить за нею?

Про це говорять дистрибутиви Debian Linux 7.6 та CentOS 7


EDIT

На цей момент я просто хотів поділитися деякими моїми висновками, які я придумав під час дослідження зв’язків між стандартними дозволами групи файлів та маскою ACL. Ось знайдені нами емпіричні спостереження:

  1. Маску ACL можна змінити:

    1. безпосередньо встановивши його setfacl -m m:<perms>командою;
    2. шляхом зміни дозволів групи файлів за допомогою chmodкоманди (якщо маска ACL вже присутня; вона може бути відсутньою, оскільки вона є необов'язковою, якщо у файлі немає дозволів користувача або групи ACL);
    3. додавши абоментований запис ACL або користувача (маска буде автоматично перерахована).
  2. Маска буде застосовувати максимальні права доступу (якщо є записи ACL з наявними дозволами, що перевищують дозволи на маску ACL), лише якщо маска встановлюється безпосередньо setfacl або шляхом зміни дозволу групи файлів з chmod (не розраховується автоматично). Будь-які зміни в записах ACL викликають автоматичний перерахунок ACL-маски та ефективно відключають "режим виконання".

  3. Існує пара побічних ефектів, які негативно впливають на стандартні дозволи файлових файлів при використанні ACL:

    1. Записаний користувачем або групою запис ACL, застосований до файлу, може змінити маску ACL (збільшити її дозволи), а отже, і ефективні дозволи групи файлів. Наприклад, якщо ви, як власник файлу, встановили на нього права "rw-r - r-- jim students", а ви також надаєте дозвіл rw користувачеві "jack", ви також неявно надаєте права доступу rw будь-кому від групи «студенти».
    2. Більш сувора (менша кількість дозволів) маска ACL може назавжди видалити відповідні стандартні дозволи файлових груп. Наприклад, якщо у вас є файл із стандартними дозволами групи файлів rw і ви застосуєте до файлу маску ACL, доступну лише для читання, його дозволи групи зменшаться до лише читання. Тоді якщо ви видалите всі розширені записи ACL (за допомогою setfacl -bкоманди), групові дозволи залишатимуться лише для читання. Це стосується лише більш жорсткої маски ACL, більш м’яка маска ACL (більше дозволів) не змінює остаточно дозвіл оригінальної групи файлів після її видалення.

Я думаю, ви можете скористатись такою сторінкою для довідок, www-uxsup.csx.cam.ac.uk/pub/doc/suse/sles9/adminguide-sles9/…
кунді

Відповіді:


11

Не має сенсу, якщо дозволи файлу unix не погоджуються із записом acl і навпаки. Відповідно, на сторінці керівництва ( acl(5)) зазначено, що ви просите:

КОРЕПОНДЕНЦІЯ МЕЖДУ ВПЛИВИ ACL І ФІЛІЙНІ ДОГОВОРИ

Дозволи, визначені ACL, є набором дозволів, визначених бітами дозволу файлу.

Існує відповідність між власником файлу, групою та іншими дозволами та конкретними записами ACL: дозволи власника відповідають дозволам запису ACL_USER_OBJ. Якщо ACL має запис ACL_MASK, дозволи групи відповідають дозволам запису ACL_MASK. В іншому випадку, якщо ACL не має запису ACL_MASK, групові дозволи відповідають дозволам запису ACL_GROUP_OBJ. Інші дозволи відповідають правам запису ACL_OTHER_OBJ.

Власники файлів, групи та інші дозволи завжди відповідають дозволам відповідного запису ACL. Модифікація бітів дозволу на файл призводить до зміни відповідних записів ACL, а зміна цих записів ACL призводить до модифікації бітів дозволу на файл.

Додаток у відповідь на обговорення:

Яка причина поєднання дозволів ACL-маски та дозволу групи файлів? Яка логіка лежить за нею?

Хороше пояснення тут . По суті маска - це

[...] верхня межа дозволів, які надає будь-який запис у груповому класі.

Це властивість верхньої межі гарантує, що додатки POSIX.1, які не знають про ACL, не будуть раптово і несподівано починати надавати додаткові дозволи, як тільки підтримуються ACL.

У мінімальних правах доступу ACL дозволи групового класу ідентичні дозволам групи. У розширених ACL-групах груповий клас може містити записи для додаткових користувачів або груп. Це призводить до проблеми: деякі з цих додаткових записів можуть містити дозволи, які не містяться у власній групі записів, тому права доступу на введення групи можуть відрізнятися від дозволів групового класу.

Ця проблема вирішується в силу запису маски. При мінімальних правах доступу ACL дозволи дозволів групового класу відображаються на права власності на групу вступу. З розширеними ACL, дозволи дозволів групового класу відображають дозволи введення маски, тоді як запис групи володіння все ще визначає права доступу групи. Відображення дозволів групового класу вже не є постійним.


Те, що ви говорите, стосується наступних результатів getfacl: user :: rw- group :: r-- other :: r-- . Ці 3 рядки будуть змінені, якщо ви використовуєте chmodкоманду для зміни стандартних дозволів, і навпаки при виконанні, скажімо getfacl -m u:someuser:rwx, стандартного дозволу на файл для власника файлу буде змінено, і зміни відобразяться у ls -lвисновку. Це все правда, але я не бачу, як це відповідає на моє запитання
golem

дивіться мою редакцію для повного оповідання
countermode

1
У вашій відредагованій відповіді йдеться про те, що між дозволами групи файлів і ACL-маскою існує конструкція зв'язку. Питання, що є причиною з’єднання дозволів ACL-маски та дозволу групи файлів, все ще не вдається. Яка логіка лежить за цим, мені незрозуміло.
голем

1
Може бути сенс. Це залежить від визначення та реалізації. За визначенням Linux файл ACL, як він реалізований зараз, є набором стандартних дозволів на файли, тобто включає їх. Тому вони не можуть "суперечити". Ось випадок використання. Якщо я призначу дозволу rwx "тестувальнику" для файлу з початковими -rw-r--r-- 1 user userдозволами, цей ім'я користувача ACL буде прийнято, а маска ACL (разом із дозволами групи файлів) також буде змінена на rwx. --- [див. наступний коментар як продовження]
голем

1
Тепер дозволи на rwx "testuser" суперечать новим -rw-rwxr-- 1 user userдозволам файлу чи ні? Як ви визначаєте протиріччя? Порівнюючи дозволи ACL тестового користувача зі стандартним дозволом групи файлів? Яка логіка змусила вас порівнювати групові дозволи з дозволами користувачів? Хіба вони не різні сутності? Хіба це не протиінтуїтивно? Для вас це, мабуть, очевидно, але я все ще намагаюся зрозуміти це.
голем

3

Нарешті я зрозумів, що саме відбувається, коли побачив це посилання Обробка ACL

Зокрема, ці маски в основному займають місце і функціонують на заміну NAMED USER та всіх дозволів GROUP. Це означає, що якщо:

  1. налаштуйте маску, ви зміните максимальні дозволи групи,
  2. якщо ви змінюєте будь-який дозвіл групи з наявною маскою, маска приймає максимальні групові дозволи всіх групових дозволів
  3. групові дозволи на читання, запис та виконання визначаються на основі маски, якщо вона є

введіть тут опис зображення

Сподіваємось, це допомагає.


На сторінці, на яку ви переглядали, є дуже приємне пояснення маски (цитата з розділу 27.3.3. Каталог з доступом ACL ): маска визначає максимально ефективні дозволи доступу для всіх записів у груповому класі. Сюди входить названий користувач, названа група та група володіння. .
patryk.beza

-1

Яка логіка лежить за нею?

Логіка повністю порушена, і таким чином POSIX ACL є чистою і марною дурницею.

Якщо вони мали на меті зберегти сумісність із програмами, які не мають поняття ACL, за винятком стандартної примітивної моделі "ugo" для UNIX, вони спочатку не спрацювали, тому що тепер кожен додаток, що очищає дозволи групи, фактично відкликає доступ, доданий ACL.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.