Чи є причина, чому існують дозволи власника? Не вистачає групових дозволів?

Думаю, я швидше розумію, як працюють дозволи файлів у Linux. Однак я не дуже розумію, чому вони розділені на три рівні, а не на два.

Я хотів би відповісти на наступні питання:

• Це навмисна конструкція чи пластир? Тобто - чи були розроблені та створені дозволи власника / групи разом з деякими обґрунтуваннями, чи вони приходили один за одним, щоб відповісти на потребу?
• Чи існує сценарій, коли користувач / група / інша схема корисна, але групової / іншої схеми буде недостатньо?

Відповіді на перші повинні цитувати підручники або офіційні дошки для обговорень.

Я вважав випадки використання:

• приватні файли - дуже легко отримати групу на кожного користувача, що часто робиться, як це робиться у багатьох системах.
• дозволяючи лише власникові (наприклад, системній службі) писати у файл, дозволяючи читати лише певній групі, а також забороняти весь інший доступ - проблема цього прикладу полягає в тому, що як тільки вимога групи має доступ до запису, користувач / група / інші не вдається з цим. Відповідь на обидва - це використання ACL, і не виправдовує IMHO існування прав власника.

NB: Я уточнив це питання після закриття цього питання на superuser.com .

EDIT виправлено ", але схеми групи / власника не вистачить" на "... група / інше ...".

Історія

Спочатку Unix мав дозволи лише для власника, а для інших користувачів: не було груп. Див. Документацію, зокрема, версії Unix 1 chmod(1). Тому зворотна сумісність, якщо нічого іншого, не вимагає дозволів для власника.

Групи прийшли пізніше. ACL, що дозволяють включати більше до однієї групи у дозволи файлів, з'явилися набагато пізніше.

Виразна сила

Наявність трьох дозволів для файлу дозволяє отримувати більш точні дозволи, ніж мати лише два, при дуже низькій вартості (набагато нижче, ніж ACL). Наприклад, файл може мати режим rw-r-----: доступний для запису лише користувачем, який читається групою.

Іншим випадком використання є встановлені виконавчі файли, які виконуються лише однією групою. Наприклад, програма з режимом, яким rwsr-x---належить, root:adminдозволяє лише користувачам adminгрупи запускати цю програму як корінь.

"Є дозволи, які ця схема не може висловити", це жахливий аргумент проти неї. Чинним критерієм є, чи є достатньо поширених чітких випадків, які виправдовують витрати? У цьому випадку вартість мінімальна, особливо враховуючи інші причини для користувача / групи / іншого триптиху.

Простота

Наявність однієї групи на користувача має невеликі, але не незначні накладні витрати. Добре, що надзвичайно поширений випадок приватного файлу не залежить від цього. Додаток, який створює приватний файл (наприклад, програма доставки електронної пошти), знає, що все, що потрібно зробити, це надати файлу режим 600. Не потрібно обходити групову базу даних, шукаючи групу, яка містить лише користувача - і що робити, якщо немає такої групи або більше однієї?

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

Ортогональність

Кожен процес виконує доступ до файлової системи як певного користувача, так і певної групи (зі складнішими правилами щодо сучасних уніцій, які підтримують додаткові групи). Користувач використовується для багатьох речей, включаючи тестування на root (uid 0) та дозвіл на доставку сигналу (на основі користувача). Існує природна симетрія між розмежуванням користувачів та груп у дозволах процесу та розмежуванням користувачів та груп у дозволах файлової системи.

Це навмисна конструкція чи пластир? Тобто - чи були розроблені та створені дозволи власника / групи разом з деякими обґрунтуваннями, чи вони приходили один за одним, щоб відповісти на потребу?

Користувач / група / інші дозволи на файл є частиною оригінального дизайну Unix.

Чи існує сценарій, коли схема користувача / групи / інша корисна, але схема групи / власника не буде достатньою?

Так, практично в кожному сценарії я міг уявити, де важлива безпека та контроль доступу.

Приклад: Ви, можливо, захочете надати деякі бінарні файли / скрипти для доступу до системи, що виконується лише для системи other, і обмежити доступ для читання / запису root.

Я не впевнений, що ви маєте на увазі для моделі дозволу на файлову систему, яка має лише права власника / групи. Я не знаю, як у вас могла бути захищена операційна система без наявності otherкатегорії.

EDIT: Припустимо, ви мали на увазі, що тут group/otherпотрібні дозволи, то я пропоную розробити спосіб керування криптографічними ключами або спосіб, щоб лише потрібні користувачі могли отримати доступ до своєї котушки пошти. Є випадки, коли приватному ключу може знадобитися суворо user:userправо власності, але інші випадки, коли є сенс надати йому user:groupправо власності.

приватні файли - дуже легко отримати групу на кожного користувача, що часто робиться, як це робиться у багатьох системах.

Зрозуміло, що це легко зробити, але це так само легко зробити з існуванням otherгрупи ...

дозволяючи лише власникові (наприклад, системній службі) писати у файл, дозволяючи читати лише певній групі, а також забороняти весь інший доступ - проблема цього прикладу полягає в тому, що як тільки вимога групи має доступ до запису, користувач / група / інші не вдається. Відповідь на обидва - це використання ACL, і не виправдовує IMHO існування прав власника.

Я виділив частину вашої заяви, яка, схоже, повторює мою думку про логічну необхідність для otherкатегорії в дозволах файлової системи Unix.

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

Це навмисна конструкція чи пластир? Тобто - чи були розроблені та створені дозволи власника / групи разом з деякими обґрунтуваннями, чи вони приходили один за одним, щоб відповісти на потребу?

Так, це навмисний дизайн, який присутній в UNIX з перших днів. Він був реалізований в системах, де об'єм пам'яті вимірювався в КБ, а центральні процесори були надзвичайно повільними за сучасними стандартами. Розмір і швидкість таких оглядів були важливими. ACL вимагало б більше місця та повільніше. Функціонально everyoneгрупа представлена ​​іншими прапорами безпеки.

Чи існує сценарій, коли схема користувача / групи / інша корисна, але схема групи / власника не буде достатньою?

Дозволи, які я зазвичай використовую для доступу до файлів, є: (я використовую бітові значення для простоти і тому, що зазвичай я їх встановлюю.)

• 600або 400: Доступ лише для користувачів (і так, я надаю доступ лише користувачу для читання).
• 640або 660: Доступ користувача та групи
• 644, 666Або 664: Користувач, група, і інший доступ. Будь-яка дворівнева схема дозволу може обробляти лише два ці три випадки. Третій потребує ACL.

Для каталогів та програм я зазвичай використовую:

• 700або 500: доступ лише для користувачів
• 750або 710: Групувати лише доступ
• 755, 777, 775, Або 751: Користувач, група, і інший доступ. Ці ж коментарі стосуються файлів.

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

Як було зазначено вище, перелічити дозвіл у списку каталогів дуже просто. Якщо ACL не використовуються, я можу перевірити дозволи доступу лише за допомогою списку каталогів. Коли я працюю з системами на основі ACL, мені дуже важко перевірити чи перевірити дозволи.

Користувач / група / інша система дозволів була розроблена до винайдення ACL. Це відноситься до перших днів UNIX, тому ви не можете сказати, що проблему слід вирішити за допомогою ACL. Навіть якщо концепція ACL здається очевидною, вона передбачала б значну [за день] кількість додаткових накладних витрат для зберігання та управління змінною кількістю інформації про дозвіл з кожним файлом, а не фіксованою сумою.

Використання ACL для всього також означає, що у вас немає чітко визначеного підмножини інформації про дозвіл, яка може бути показана "з першого погляду". Вихідні дані для ls -lстандартних дозволів (користувач / група / інші), ім'я користувача та групи та додаткові позначення (наприклад, +або @знак) для записів, у яких асоційований ACL, все в одному рядку. Вашій системі потрібно, щоб вона ідентифікувала "дві найкращі" групи в ACL, щоб забезпечити еквівалентну функціональність.

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