Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

совкомбанк исправление кредитной истории У вас отключен JavaScript. Некоторые возможности системы не будут работать. Пожалуйста, включите JavaScript для получения доступа ко всем функциям.

Списки контролю доступу

  — Що це?— витягнув шию Гмик, похмуро дивлячись на мої карти. — Але тут,же лише.
— Хвилинку, — втрутився гравець зліва від нього. — Сьогодні вівторок. Виходить, його однороги дикі.
— Але в назві місяця є "М"— вякнул ще хтось. — Значить, його велетень йде за половину номінальної вартості!
— Але у нас парне число гравців...
— Ви все дещо упускаєте. Ця партія — сорок третя, а Ськив сидить на стільці лицем на північ!
Прийнявши за вказівку стогони і вираження відрази, що все помітніше вимальовувалося, на лицях, я згріб банк.
Р. Аспрін

У спільному випадку сукупність всіх ACL в системі є тривимірною матрицею, рядки якої відповідають користувачам, стовпцями -операциям над об'єктами, а шари — самим об'єктам. Із зростанням кількості об'єктів і користувачів в системі об'єм цієї матриці швидко зростає, тому, як вже говорилося, розробники реальних систем контролю доступу роблять ті або інші заходи для компактнішого представлення матриці.
Хоча хитрування для скорочення ACL дають певний ефект, і в більшості випадків список має всього лише декілька записів (мал. 12.9), накладення обмежень на його розмір часто вважають неприйнятними або встановлюють такі обмеження вельми високими, наприклад в декілька тисяч записів. Це приводить до того, що з файлом у ФС, що підтримують списки контролю доступу, окрім основного масиву даних, виявляється зв'язаний ще один масив, зазвичай поступливий в розмірах основному, але, в принципі, здатний досягати дуже великого об'єму.
Втім, відповідне ускладнення файлової системи не так вже велике. Багато хто ФС дозволяє зберігати в додаткових блоках даних не лише записи ACL, але і іншу суть — розширені атрибути, ресурсну гілку і так далі

Мал. 12.9. Список контролю доступу

Є три основні підходи, використовуваних для скорочення ACL.

  • Використання прав за умовчанням
  • Групування користувачів і об'єктів
  • Обмеження комбінацій прав, якими користувачі і групи можуть реально володіти

Права за умовчанням дають найбільший ефект тоді, коли велика частина прав більшості користувачів на більшість об'єктів однакова. Найчастіше рекомендують при встановленні прав виходити з принципу "заборонено все, що не дозволене [явним чином]" — при послідовному його вживанні повинно виходити, що більшість користувачів не мають прав на переважну частину об'єктів в системі. Виходячи з цього, в більшості систем користувачі, явно або неявно не перераховані в ACL об'єкту, не мають на об'єкт жодних прав. Багато систем також надають спеціальний запис в ACL, відповідну користувачам, які не перераховані явно.
Об'єднання користувачів в групи є більш універсальним засобом, який корисний не лише для скорочення ACL, але і для інших цілей. Група вводить додатковий рівень побічності (ACL посилається на користувача не прямо, а побічно, через групу в систему встановлення прав і управління ними, і це дає додаткову гнучкість, корисну в багатьох практичних випадках (мал. 12.10).

Мал. 12.10. Групи користувачів

Так, в більшості випадків повноваженнями наділяють людину не за те, що він такий хороший, а тому, що вони потрібні йому для виконання службових обов'язків. Зміна службових обов'язків (постійне, при переході на іншу посаду, або тимчасове, наприклад, при заміні хворого або такого, що пішов у відпуск співробітника) супроводиться зміною прав, якими користувач повинен володіти.
У цій ситуації доцільно створити гурт, відповідний тій або іншій посаді, і видавати права на об'єкти цій групі. Призначення людини на посаду супроводиться включенням його у відповідну групу, а зняття — виключенням з неї. Без використання груп ці операції потребоваті б явної модифікації ACL всіх об'єктів, права на яких змінюються, що у багатьох випадках абсолютно нераціонально.
Групи яшшотся практично обов'язковим елементом систем упраатенія правами на основі списків. Більшість систем надає можливість створення вкладених груп (мал. 12.11). Ряд сучасних систем (Novell Netware 4..Y, Windows 2000, Solans 6) надають також ієрархічні структури БД облікових записів, чомусь звані службами каталогів (NDS -netware Directory Service в Netware, Active Directory в Windows, Nis+ - - Network Information Service в Solans). Вперше служба каталогів була реалізована в мережевій ОС VINES (Virtual Network Services) фірми Banyan Systems в кінці 80-х.

Мал. 12.11. Вкладені групи і структура організації

Ієрархічна структура особливо зручна для великих організацій, бо вона не лише забезпечує "природну" структуру вкладених груп, але і полегшує перегляд облікових записів і управління ними.
При активному використанні груп користувачів може виникнути специфічна проблема: користувач може полягати в декількох групах і мати власний запис в ACL і, таким чином, отримувати права на об'єкт декількома дорогами (мал. 12.12). Строго кажучи, проблемою це не є, поважно лише описати, що відбуватиметься з правами в цьому випадку. У різних системах використовуються майже всі мислимі варіанти поведінки.

Мал. 12.12. Отримання прав з декількох груп

Частіше за все право, отримані різними дорогами, просто складаються. Бувають системи, в яких окремі права тим або іншим чином ранжируються, і користувач отримує список прав, відповідний тому запису в ACL, який містить найвище право. Дуже часто деякі записи в ACL володіють особливим статусом. Так, якщо людина має явний (відповідну його призначеному для користувача ідентифікатору) запис в ACL, записані в ній права виявляються "сильнішими" за всі права, які він отримує як член групи. Запис з правами за умовчанням часто розглядається як "слабкіша", ніж явні і групові записи, і за наявності у користувача прав, отриманих із записів за умовчанням, взагалі ігнорується.
Кожне з цих правил окремо зазвичай Переслідує мету полегшити формування списків, що надають необхідні комбінації прав, але в результаті повний опис семантики ACL багатьох поширених ОС нагадує винесені в епіграф фрагменти правил гри в "драконівський покер".
Групування об'єктів використовується декілька рідше, але також є потужним засобом управління правами і скорочення спільного об'єму ACL в системі. Для файлових систем природним засобом групування є ієрархія каталогів.

Спадкоємство прав на файли в Novell Netware
Мабуть, найбільшої складності групування об'єктів досягло в системі Novell Netware. Розглянемо схему встановлення прав на файли в цій ОС.
Запис файлового ACL в Netware є бітовою маскою, значення розрядів якої перераховані в таблиці. 12.1. Видно, що деякі з прав мають сенс лише для файлів, а деякі — лише для каталогів.
Каталоги і файли в цій системі успадковують права доступу від батьківських каталогів. Якщо користувач або група не перераховані явно в ACL об'єкту, їх ефективні права визначатимуться записами в ACL батьківських каталогів (мал. 12.13). Якщо користувач перерахований в ACL батьківського і дочірнього каталогів, його ефективні права дорівнюватимуть сумі прав, вказаних в обох записах. Таким чином, у міру спуску по дереву каталогів, ефективні права можуть лише зростати.

Мал. 12.13. Спадкоємство прав на каталоги в Novell Netware (позначення прав відповідають таблиці. 12.1)

При цьому користувач не зобов'язаний мати права на каталог, щоб бачити його файли і підкаталоги. Тому система управління доступом Netware передбачає видачу прав як можна ближче по дереву каталогів до тих файлів, права на яких необхідні. Права на кореневі каталоги томів зазвичай видаються лише адміністраторові системи.
У випадку якщо все-таки потрібно буде змінити принцип розширення прав у міру спуску по дереву, каталоги і файли, окрім ACL, мають додатковий атрибут, званий IRF (Inherited Rights Filter— фільтр успадкованих прав). Цей атрибут є бітовою маскою, біти якої (окрім біта S — він не може бути відфільтрований) відповідають бітам запису ACL (див. таблиці. 12.1). Установка біта в цій масці приводить до блокування спадкоємства відповідного права (мал. 12.14).

Мал. 12.14. Фільтр успадкованих прав в Novell Netware

Заборона на фільтрацію права супервізора обумовлена тим, що його включення помилково приведе до втрати адміністратором прав на цю ієрархію. Позбавитися від такого поддерева можна було б лише переразметкой томи.
У призначеній для користувача базі даних, яка, починаючи з Netware 4.x, також має ієрархічну структуру, і спадкоємство, блокування супервізорських прав дозволене, тому можна помилково "дарувати суверенітет" гілки дерева (мал. 12.15). Це одна з поширених помилок початкуючих адміністраторів. У адміністративних утилітах Netware 4.11 навіть була введена спеціальна перевірка, що не дозволяє відфільтрувати право супервізора, якщо ні у КТО немає явно виданих супервізорських прав на відповідний контейнер або об'єкт.

Мал. 12.15. Дарування суверенітету гілці дерева каталогів

Таблиця 12.1. Права доступу до файлу в Novell Netware 3.x і вище

Біт
Позначення
Опис
S
Supervisor
Право здійснювати будь-які операції над файлом або каталогом
А
Access
Право модифікувати ACL файлу або каталога
R
Read
Право читати файл
З
Create
Право створювати файли в каталозі
W
Write
Право запису у файл
Е
Erase
Право видаляти файл або каталог
М-код
Modify
Право змінювати атрибути файлу або каталога
F
Find
Право на пошук файлів в каталозі

Альтернативою цим хитрощам є третій із згаданих доріг -ограніченіє комбінацій прав, які реально можуть бути видані. З одним з прикладів такого обмеження ми стикалися в разд. Сегменти, сторінки і системні виклики : диспетчер пам'яті VAX має чотири рівні привілеїв, кожен з яких може мати право читання і запису в сторінку пам'яті. Всі можливі комбінації прав в цих умовах кодуються 8-у бітами, але накладення вимоги про те, що кожен вищий рівень зобов'язаний мати хоч би ті ж права, що і нижчі, дозволяє нам обійтися 15-у допустимими комбінаціями і 4-мя бітами для їх кодування.
При розробці такої системи ми стикаємося з нетривіальним завданням: нам потрібно виробити такі обмеження, які не лише забезпечували б компактне представлення ACL, але і дозволяли так чи інакше реалізувати комбінації прав, необхідні для практичної експлуатації обчислювальних систем.
Чудовим прикладом обмеженого ACL, структура якого витримала 30-річну перевірку практикою, є модель безпеки в системах сімейства Unix.

Авторизація в Unix
У цих системах ACL складається рівно з трьох записів (мал. 12.16).
Права господаря файлу (користувача)
Права групи
Права за умовчанням

Мал. 12.16. Встановлення прав в системах сімейства Unix

Як правило, права господаря вищі за права групи, а права групи вище за права за умовчанням, але це не є обов'язковою вимогою і ніким спеціально не перевіряється. Користувач може належати до декількох груп одночасно, файл завжди належить лише одній групі.
Бувають три права: читання, записи і виконань. Для каталога право виконання означає право на відкриття файлів в цьому каталозі. Кожне з прав позначається бітом в масці прав доступу, тобто всі три групи прав представляються дев'ятьма бітами або трьома вісімковими цифрами.
Права на видалення або перейменування файлу не існує; взагалі, в Unix не визначена операція видалення файлу як така, а існує лише операція видалення імені unlink. Це пов'язано з тим, що файл в Unix може мати декілька імен, і власне видалення відбувається лише при знищенні останнього імені (детальніше за див. главу 11). Для видалення, зміни або створення нового імені файлу досить мати право запису в каталог, в якому це ім'я міститься.
Видалення файлів з каталога, насправді, можна в певних межах контролювати: установка додаткового біта (маска прав містить не дев'ять, а дванадцять біт, з семантикою ще два з них ми познайомимося в разд. Зміна ідентифікатора користувача) забороняє видалення з каталога чужих файлів. Володар права запису в такий каталог може створювати в нім файли і видаляти їх, але лише до тих пір, поки вони належать йому.
Окрім прав, перерахованих в масці, господареві файлу дозволяється змінювати права на файл: модифікувати маску прав і передавати файл іншій групі і, якщо це необхідно, іншому користувачеві (у системах з дисковими квотами передавати файли зазвичай забороняють).
Ще один володар прав на файл, не вказаний явно в його ACL, — це адміністратор системи, користувач з ідентифікатором, рівним 0. Цей користувач традиційно має символічне ім'я root. Повноваження його по відношенню до файлів, інших об'єктів і системи в цілому правильніше описати навіть не як володіння всіма правами, а як можливість робити з представленими в системі об'єктами що завгодно, не звертає уваги на права.
У традиційних системах сімейства Unix всі глобальні об'єкти — зовнішні пристрої і іменовані програмні канали — є файлами (точніше, мають імена у файловій системі) і управління доступом до них виконується файловим механізмом. У сучасних версіях Unix адресні простори процесів, що виконуються, також доступні як файли в спеціальній файловій (або псевдофайловою, якщо завгодно) системі ргос. Файли в цій ФС можуть бути використані, наприклад, відладчиками для доступу до коду і даних відладжуваної програми (мал. 12.17). Управління таким доступом також здійснюється стандартним файловим механізмом.
У Unix System V з'явилися об'єкти, що не є файлами і що ідентифікуються чисельними ключами доступу замість імен, а саме засоби межпроцессного взаємодії: це семафори, черги повідомлень і сегменти пам'яті, що розділяється. Кожен такий об'єкт має маску прав доступу, аналогічну файловою, і доступ до нього контролюється точно так, як і до файлів.

Основна перевага цього підходу полягає в його простоті. Фактично це найбільш проста з систем привілеїв, придатна для практичного вживання. Іншими словами, простіші і обмежені системи встановлення привілеїв, мабуть, непридатні взагалі.

Мал. 12.17. Дерево каталогів Unix

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

 

:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017