логін і su внутрішні

Я намагаюся зрозуміти, як працюють дозволи користувачів у Linux. Ядро завантажується і починається initяк root, правда? Потім Init запускає сценарії запуску і запускає getty( agetty), знову як root. Agetty просто читає ім’я користувача і працює login, все ще як root, я думаю. Ще нічого цікавого. Але що робить логін ? Я не зміг знайти нічого кращого, ніж "це спроби увійти". Припустимо, логін виявляє, що пароль відповідає (і ми намагаємось увійти як звичайний користувач), як це змінює ідентифікатор користувача? Я думав, що для цього повинен бути системний виклик, але я не зміг його знайти (можливо, я просто сліпий?)

Також о su. suвстановлений біт 'setuid', тому коли ми запускаємо його, він завжди працює як root. Але коли ми кажемо йому увійти як звичайний користувач, йому знову потрібно змінити ідентифікатор користувача. Чи правильно я розумію, що та ж сама "магія" відбувається suі loginколи їм потрібно змінити користувача? Якщо так, то навіщо дві різні програми? Чи є якісь додаткові види серйозного бізнесу, коли відбувається вхід у систему?

Існує кілька частин того, що роблять програми для входу. Програми для входу відрізняються тим, як вони взаємодіють із користувачем, який намагається увійти. Ось кілька прикладів:

• login: читає введення на текстовому терміналі
• su: викликається вже зареєстрованими користувачами, отримує більшість даних із аргументів командного рядка, а також дані автентифікації (пароль) з терміналу
• gksu: аналогічно su, але зчитує дані аутентифікації в X
• rlogind: отримує вхід через TCP-з'єднання через протокол rlogin
• sshd: отримує вхід через TCP-з'єднання через протокол SSH
• Менеджери дисплеїв X (xdm, gdm, kdm, ...): подібні login, але вхід зчитується на X-дисплеї

Ці програми діють аналогічно.

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

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

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

4. Нарешті програма входу налаштовує сеанс користувача. Існує декілька підстопів:

   1. Встановіть дозволи процесу на те, що було вирішено в авторизації: користувач, групи, обмеження ... Тут ви можете побачити простий приклад цього підкроку (він обробляє лише користувачів та групи). Основна ідея полягає в тому, що програма входу до цих пір працює як корінь, тому вона має максимальні привілеї; він спочатку видаляє всі привілеї, окрім того, що він є користувачем root, і нарешті закликає setuidскинути цю останню, але не менш важливу привілей.
   2. Можливо, змонтуйте домашній каталог користувача, покажіть повідомлення "у вас є пошта" тощо.
   3. Викликати якусь програму як користувача, як правило, оболонку користувача (для loginта su, або sshdякщо не вказано жодної команди; менеджер дисплеїв X викликає менеджера сеансів X або менеджера вікон).

Більшість уніцій сьогодні використовують PAM (Pluggable Authentication Modules), щоб забезпечити єдиний спосіб управління послугами входу. PAM розділяє свою функціональність на 4 частини : "auth" охоплює як автентифікацію (1 вище), так і авторизацію (2 вище); "Рахунок" і "сесія" наведені вище, як 3, і 4; а також "пароль", який використовується не для входу в систему, а для оновлення маркерів аутентифікації (наприклад, паролів).

Системні дзвінки, які ви шукаєте, називаються такими, як, setuidі seteuidхоча насправді існує ціле сімейство подолів залежно від того, які саме варіанти ідентичності користувача ви намагаєтеся змінити.

Існують також паралельні дзвінки, такі як setgidзміна групи, в якій працює процес.

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

Насправді скидання кореневих привілеїв досить тривіально. POSIX визначає setuid()та setgid()функції, які змінюють ідентифікатори користувачів та групи відповідно (реальні та ефективні, якщо ви починаєте як root). loginвимагає обох, а також initgroups()налаштування будь-яких додаткових груп, які можуть бути у вас (оскільки setgidце лише для встановлення вашого основного ідентифікатора групи)

Звичайно, це ядро, яке насправді обробляє зміну UID / GID процесу. Як я можу знайти реалізацію системних викликів ядра Linux? багато пояснює про систематичні дзвінки; у своєму джерелі ядра у мене є:

#define __NR_setgid 144
__SYSCALL(__NR_setgid, sys_setgid)
#define __NR_setuid 146
__SYSCALL(__NR_setuid, sys_setuid)

тому 144 і 146 - номери системних викликів цих функцій на моїй машині

Я не перевіряв suджерело, щоб побачити, що воно робить, але я підозрюю, що воно також скидає права root перед тим exec(), як використовувати оболонку, використовуючи той самий метод