Перегляд вихідного коду сторінки Спеціальні права доступу (suid, sgid, sticky)

== suid і sgid ==
У момент вашого входу в систему запускається новий процес оболонки. Ви вже знаєте про це, але можете не знати про те, що цей новий процес оболонки (зазвичай це bash) працює від імені вашого користувача. І таким чином програма bash може звертатися до всіх файлів і тек, власником яких ви є. Насправді ми, як користувачі, повністю залежний від програм, що виконують операції від нашого імені. І оскільки програми, які ви запускаєте, успадковують ваш користувальницький ідентифікатор, вони не можуть звертатися об'єктів файлової системи, до яких вам не надано доступ. Приміром, звичайні користувачі не можуть безпосередньо змінювати вміст файлу passwd бо прапор записи вимкнено для всіх користувачів крім root:

$ Ls-l / etc / passwd

-Rw-r - r - 1 root wheel 1355 Nov 1 21:16 / etc / passwd
Однак, звичайним користувачам теж потрібно мати можливість хоча б опосередковано змінювати вміст / etc / passwd коли їм знадобиться змінити пароль. Але якщо користувач не може змінити цей файл, як це зробити?

suid

В моделі прав доступу Linux є два спеціальних біта, 
званих suid і sgid. Коли для запускається програми встановлений біт suid, вона буде працювати від імені власника виконуваного файлу, а не від імені того, хто запустив програму. Тепер можемо повернутися до питання з / etc / passwd. Якщо подивимося на виконуваний файл passwd, побачимо, що його власником є користувач root:

$ Ls-l / usr / bin / passwd

-Rwsr-xr-x 1 root wheel 17588 Sep 24 00:53 / usr / bin / passwd

Зверніть увагу, що замість x в триплеті прав доступу власника варто s. Це означає що для цієї конкретної програми встановлені біти suid і права на запуск. З цієї причини при запуску програми passwd вона буде працювати від імені користувача root (з усіма правами доступу суперкористувача), а не користувача, що запустив її. І оскільки passwd працює з правами root, вона здатна редагувати / etc / passwd без будь-яких складнощів.


== Попередження про suid / sgid ==
Ми побачили як працює suid, sgid працює схожим чином. Вона дозволяє програмі успадковувати права доступу групи, а не поточного користувача.
Важливо!
Трохи розрізнена, але в той же час дуже важлива інформація про suid і sgid. По-перше, біти suid і sgid займають ті ж поля у виведенні команди ls-l. Якщо біт x теж заданий, відповідні біти будуть показані як s (у нижньому регістрі). Однак, якщо біт x не заданий то він буде відображатися як S (у верхньому регістрі).
Важливо!
Ще одне важливе зауваження: suid і sgid бувають зручні в багатьох ситуаціях, але неправильне їх використання може призвести до появи вразливостей в захисті системи. Найкраще мати якомога меншу кількість suid програм. Команда passwd - одна з не багатьох, яка повинна бути suid.


== Зміна suid і sgid ==
Спосіб установки і видалення бітів suid і sgid надзвичайно простий. Ось так ми задаємо біт suid:

# Chmod u + s / usr / bin / myapp
 А в наступному прикладі ми знімаємо прапор sgid з директорії. 
Ви побачите, як біт sgid працює з директоріями нижче:
# Chmod g-s / home / drobbins


== Sticky ==

Біт, якому в коді режиму доступу відповідає вісімкове значення 1000, називається sticky-бітом ("sticky" - липучка). Це хороший приклад того, як UNIX в міру дорослішання позбувається рудиментів, але вони продовжують слідувати за системою по п'ятах. У системах з невеликою пам'яттю, наприклад PDP-11/70, де UNIX працювала у свої ранні роки, було потрібно, щоб окремі програми постійно залишалися в пам'яті. Тоді sticky-біт був дуже важливий, так як забороняв вивантаження програм з пам'яті. Сьогодні у світі 25-доларових модулів пам'яті і швидкодіючих дискових накопичувачів sticky-біт нікому не потрібний, і сучасні ядра просто ігнорують його.
Якщо sticky-біт встановлюється для каталогу, то більшість версій UNIX дозволяють видаляти і перейменовувати його файли тільки в тому випадку, якщо користувач є власником каталогу, власником файлу або користувачем root. Мати одне лише дозвіл на запис у каталог недостатньо. Така міра направлена на те, щоб зробити каталоги зразок / tmp більш захищеними.
Системи Solaris і HP-UX не такі суворі щодо каталогів з встановленим sticky-бітом. Користувач, що має право запису в такий каталог, може видаляти з нього файли, навіть якщо він не є їх власником.