5.5.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-файлі підкачування, котрий використовується в разі недостачі обсягу ОЗУ й у деяких інших випадках). Це корисно для часто використовуваних файлів загального користування, котрі виконуються. На практиці такі файли зустрічаються не надто часто.