3.4. Захист даних

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

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

Для будь-якої системи захисту характерна наявність, принаймні, трьох компонент.

· Список користувачів системи, містить імена, паролі і привілеї, присвоєні користувачам.

· Наявність атрибутів захисту у файлів та інших об'єктів, що захищаються. Ці атрибути вказують, хто з користувачів має право доступу до даного об'єкту і які саме операції йому дозволені.

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

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

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

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

3.5. Поділ файлів між процесами

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

Може призвести. Якщо один процес оновлює дані у файлі, а інший в цей час намагається читати ці ж дані, то він може прочитати частково оновлені дані. Ще небезпечніше, коли два процеси намагаються одночасно змінити одні й ті ж дані. У цьому випадку важко навіть передбачити, що в результаті буде збережено у файлі.

В принципі, завжди безпечними є лише два крайніх випадку:

· Тільки один процес працює з файлом, виконуючи читання і запис;

· З файлом працює довільне число процесів, але всі вони виконують тільки читання.

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

Типове рішення полягає в наступному. Прикладна програма, викликаючи системну функцію відкриття файлу, вказує два додаткові параметри: режим доступу та режим поділу.

Режим доступу визначає, які операції сам процес збирається виконувати з файлом. Зазвичай розрізняють доступ «тільки для читання», «тільки для запису», «для читання і запису».

Режим поділу визначає, які операції даний процес готовий дозволити іншим процесам, які захочуть відкрити той же файл. Зразковий набір режимів поділу - «заборона запису», «заборона читання», «заборона читання і запису» і «без заборон».

Перший процес, який відкриває файл, встановлює на свій розсуд режими доступу і розподілу. Коли другий процес намагається відкрити той же файл, ОС перевіряє дві умови:

· Режим доступу другого процесу не повинен суперечити режиму поділу, встановленому першим процесом;

· Режим поділу, запитуваний другим процесом, не повинен забороняти той режим доступу, який вже встановив для себе перший процес.

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

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

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

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