
- •Лабораторна робота № 10 основи роботи з операційною системою unix
- •1 Мета роботи
- •2 Основні положення
- •2.1 Загальна характеристика ос сімейства unix
- •2.2 Архітектура unix
- •2.3 Функціонування системи unix
- •2.3.1 Ядро системи
- •2.3.2 Початок і завершення сеансу робіт
- •3 Контрольні запитання
- •4 Домашнє завдання
- •5 Лабораторне завдання
- •6 Зміст протоколу
- •2.1 Основні характеристики FreeBsd
- •2.2 Історична довідка
- •2.3 Мета проекту FreeBsd
- •2.4 Вимоги до системи при інсталяції FreeBsd
- •3 Контрольні запитання
- •4 Домашнє завдання
- •5 Лабораторне завдання
- •2.1 Поняття процесу
- •2.2 Компоненти процесу
- •2.2.1 Ідентифікатор процесу
- •2.2.2 Ідентифікатор батьківського процесу
- •2.2.3 Ідентифікатор користувача і групи
- •2.3 Стан процесу, "заблукалі" процеси
- •2.4 Управління процесами, команди kill та nice
- •2.4.1 Дворівнева схема керування процесами
- •2.4.2 Команда kill
- •2.4.3 Команда nice
- •2.5 Поточний контроль процесів, команди ps та top
- •2.6 Захист фонових процесів, команда nohup
- •3 Ключові запитання
- •4 Домашнє завдання
- •5 Лабораторне завдання
- •6 Зміст протоколу
- •7 Список рекомендованої літератури
- •Лабораторна робота № 13 права доступу в операційній системі unix
- •1 Мета роботи
- •2 Основні положення
- •2.1 Поняття прав доступу користувача
- •2.2 Основні біти доступу (читання/запис/виконання)
- •2.3 Додаткові біти доступу
- •2.4 Сполучення бітів доступу
- •3 Контрольні запитання
- •4 Домашнє завдання
- •5 Лабораторне завдання
- •2.1 Основні поняття клієнт-серверної архітектури
- •2.2 Основи мережного програмування
- •2.3 Компіляція
- •3 Контрольні запитання
- •4 Домашнє завдання
- •5 Лабораторне завдання
- •6 Зміст протоколу
- •7 Список рекомендованої літератури
- •Основні комбінації клавіш і команди
- •Закінчення таблиці а2
- •Закінчення таблиці а4
- •Приклади програм для реалізації клієнт-серверної архітектури
- •Перевірка буфера
- •Зчитування запису
- •Лістинг 2 Server-сервер, котрий демонструє застосування функції readvrev
2.3 Додаткові біти доступу
Окрім розглянутих вище бітів (читання, запис та "виконуваність"), що встановлюються роздільно по трьох категоріях користувачів, є ще три біти доступу, які можна віднести до файла в цілому, оскільки їхня дія не залежить від того, який користувач, з якої категорії намагається звернутися до файла. Та й призначення цих бітів полягає не в обмеженні доступу до файла чи директорії, а в зміненні певних властивостей файлів директорій.
Біт suid розшифровується як Set user ID, перекладається як "установити ідентифікатор користувача". Оскільки адекватного українського терміна не існує, його зазвичай називають "суїдний" біт, а файли, на яких його установлено— "суїдними". Призначення його полягає в тому, що якщо його установлено на файлі, котрий є програмою, то при виконанні ця програма автоматично змінює "ефективний userID" на ідентифікатор того користувача, котрий є власником цього файла. Тобто, незалежно від того, хто запускає цю програму, вона при виконанні має права хазяїна цього файла. Зазвичай це робиться для того, щоби користувач міг виконати дії, котрі потребýють привілеїв rооt'а (наприклад, змінити свій пароль), а власником такої програми має бути користувач root.
Зрозуміло, що така програма є потенційно "небезпечною". У "нормальному" випадку вона не дозволить звичайному користувачеві зробити те, що виходить за межі його повноважень, наприклад, програма passwd дозволить користувачеві змінити лише власний пароль, але не паролі інших користувачів. Але навіть незначна помилка в такій програмі може призвести до того, що "зловмисник" зможе змусити її виконати ще якісь дії, не передбачені автором програми. До речі, більшість відомих способів "зламу" системи полягають не в тім, щоб довідатися пароля rооt'а, а саме в тім, щоби змусити котрусь із "суїдних" програм виконувати дії, необхідні "зламувачеві". Це не є єдиний шлях змінити "ефективний userID". Це можна зробити із самої програми, викликавши спеціальну системну функцію, але для цього програма має вже мати права rооt'а. Тобто її має запустити користувач root або вона має бути "суїдною", як зазначено вище.
У такого файла permissions виглядають як **s******, якщо ще й встановлено біт x для власника файла, чи як **S******, якщо біт x не встановлено. Однак ставити suid біт на невиконувані файли зазвичай не має сенсу (принаймні в FreeBSD), хоча існують програми, які перевіряють цей біт навіть для текстових файлів. Цей біт не містить жодного значення, якщо його поставити на директорію, хоча ніхто не забороняє це вчинити.
Біт sgid. Розшифровується як Set group ID, перекладається як "установити ідентифікатор групи". Цей зміст є аналогічний змістові попереднього біта, лише змінюється не ідентифікатор користувача, а ідентифікатор групи. Тобто при виконанні цього файла він має такі права, начебто його запустив дехто із групи, приписаної до цього файла.
Permissions такого файла виглядають як *****s*** (якщо встановлено біт x для групи) чи *****S** (якщо відповідного біта x немає). Так само, як і в попередньому випадку, біт sgid для невиконуваних файлів жодного значення не має.
Для FreeBSD (й інших BSD-систем) цей біт, знову ж, не чинить жодної дії. Але в деяких інших Unix-системах він означає, що, коли файли створюються в такій директорії, в їхніх атрибутах проставляється та сама група, що й у директорії. Тобто файли, створювані в такій директорії, "успадковують" групу від директорії.
Біт sticky. У жодний спосіб не розшифровується, перекладається як "липкий". Виглядає в permissions, як ********t, якщо використовується разом з бітом x для "всієї решти" чи як ********T, якщо відповідного біта x немає.
Для директорій його значення полягає в тім, що вилучити файл із такої директорії (чи перейменувати) здатен лише власник файла. В звичайному випадку (без такого біта) можливість вилучати файли (як і створювати) визначається правом запису (біт w) на директорії. Тобто, якщо якийсь користувач належить до категорії, для якої дозволено запис у директорію, він може вилучити в ній який завгодно файл, незалежно від атрибутів (власника, групи, permissions) самого файла.
Застосовують цей біт, зазвичай, на директоріях, які є "публічними" (наприклад /tmp). Такі директорії мають права доступу, котрі дозволяють усім користувачам створювати там свої файли й вилучати їх. Однак було б неправильно, якби кожний інший користувач міг помилково чи "аби нашкодити" вилучати файли, до яких він не має жодного відношення. Для того аби запобігти можливості вилучення файла "стороннім" користувачем, саме і слугує sticky біт. Цей біт може ставитися також на виконувані файли. У цьому разі він означає, що файл, навіть після завершення роботи, має залишатися в пам’яті (не в ОЗУ, а в swap-файлі підкачування, котрий використовується в разі недостачі обсягу ОЗУ й у деяких інших випадках). Це корисно для часто використовуваних файлів загального користування, котрі виконуються. На практиці такі файли зустрічаються не надто часто.