Відповіді:
Ви можете знати нормальні дозволи на читання, запис та виконання файлів у unix.
Однак у багатьох програмах така структура дозволів - наприклад, дається користувачеві або повний дозвіл на читання певного файлу, або взагалі не має дозволу на читання файлу - занадто груба. З цієї причини Unix включає ще один біт дозволу, set-user-IDбіт. Якщо цей біт встановлений для виконуваного файлу, тоді, коли інший користувач, крім власника, виконує файл, той користувач отримує всі права доступу до читання / запису / виконання файлу власника під час доступу до будь-якого з інших файлів власника!
Щоб встановити біт set-user-ID для файлу, введіть
chmod u+s filename
Переконайтеся, що ви також встановили дозвіл на виконання для інших груп; Було б непогано мати також дозвіл на читання для інших груп. Все це можна зробити за допомогою одного твердження
chmod 4755 filename
Його також називають збереженим UID. Файл, який запускається з бітом Set-UID, збережений UID буде UID власника файлу. В іншому випадку збережений UID буде Реальним UID.
Цей UID використовується для оцінки привілеїв процесу для виконання певної дії. EUID може бути змінено на Real UID або Superuser UID, якщо EUID! = 0. Якщо EUID = 0, його можна змінити на будь-що.
Прикладом такої програми є passwd. Якщо ви перерахуєте його повністю, ви побачите, що він має біт Set-UID, а власник "root". Коли звичайний користувач, скажімо, "mtk", працює passwd, він починається з:
Real-UID = mtk
Effective-UID = mtk
Saved-UID = root
man credentialsє хорошим джерелом інформації в даному випадку. Дивіться також це питання на SO . Для історичного пояснення дивіться цю архівну публікацію .
Замість того, щоб називати механізм "встановити UID" та "ефективний UID", слід назвати всю концепцію UID. Обґрунтуванням існування різних UID є різні проблеми з розділенням привілеїв. Навіть звичайним (непривілейованим) користувачам іноді потрібно робити речі (доступ до ресурсів), які можуть лише привілейовані користувачі. Щоб цього легко досягти, програми можуть змінювати свої UID. Існує 3 типи:
реальний UID - UID, який належить процесу
ефективний UID - UID, який зараз працює процес - це визначає реальні можливості процесу в будь-який конкретний момент. Це також psпоказано у полі USER.
збережений набір UID - заповнювач, що використовується для перемикання між реальним та ефективним UID
Необхідність останнього випливає з того, що постійні користувачі можуть перемикатися лише між цими трьома і нічим іншим, а налаштована програма зазвичай повинна якось знати, хто був користувачем, який її завантажив (плюс реальний UID не слід змінювати, оскільки це створило б ще більший безлад).
Розширення mtk - це добре.
passwdПрикладом може служити одна з привілеїв - PASSWD завжди працює як корінь , так як він повинен змінити файли , які тільки коренева дозволено змінювати. Це робить важливим, щоб виконуваний файл passwd не був схильний до переповнення буфера тощо, таким чином, щоб розумний звичайний користувач міг використовувати його для використання, для якого не призначено.
Інше обґрунтування - захищати користувача таким же чином, як ви могли використовувати його, suякщо ви ввійшли в систему як root - щоб зменшити або обмежити ваші привілеї для конкретних завдань, а не збільшувати їх. Наприклад, якщо я маю дозвіл на запуск служби демона, яка не потребує доступу до моїх речей та має власні речі, що є все, що їй потрібно (наприклад, реєстратор), запустивши його suid, це означає, що він має лише доступ до цього матеріалу а не мої чи будь-які інші.
Зауважте, що можна задати uid програмно, навіть якщо біт suid не встановлений у виконуваному файлі , однак це не буде працювати для ескалації. Тобто, якщо ви звичайний користувач і пишете програму, яка встановлює uid в якийсь момент сама, ця програма не може переключитися на root. Apache працює так, я вважаю. Зазвичай він починається з root і має один процес, який потім спрямовує дітей, які перемикають uid на непривілейованого користувача (наприклад, "httpd"). Ці дочірні процеси - це те, чим працює власне веб-сервер.