логин и су внутренности

Я пытаюсь понять, как пользовательские разрешения работают в 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, поэтому она имеет максимальные привилегии; сначала он удаляет все привилегии, кроме того, чтобы быть пользователем root, и, наконец, вызывает setuidсброс этой последней, но не менее важной привилегии.
   2. Возможно смонтировать домашний каталог пользователя, отобразить сообщение «у вас есть почта» и т. Д.
   3. Вызвать какую-либо программу от имени пользователя, обычно это оболочка пользователя (для loginи su, или, sshdесли команда не указана; диспетчер отображения X вызывает диспетчер сеансов X или диспетчер окон).

В настоящее время большинство офисов используют PAM (Pluggable Authentication Modules) для обеспечения единого способа управления сервисами входа в систему. PAM делит свою функциональность на 4 части : «auth» охватывает как аутентификацию (1 выше), так и авторизацию (2 выше); «Account» и «session» такие же, как 3 и 4 выше; и есть также «пароль», который используется не для входа в систему, а для обновления токенов аутентификации (например, паролей).

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

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

loginудалит привилегии root при необходимости. Многие программы, которым требуются привилегии root только на начальном этапе, будут запускаться от имени пользователя root, делать то, что им нужно, а затем переходить к обычной учетной записи пользователя, чтобы им не приходилось беспокоиться о том, что кто-то использует ошибку в двоичном файле для получения доступа к корневая оболочка. loginестественно, дольше держит привилегии, но принцип тот же.

На самом деле удаление привилегий root довольно тривиально. 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()использованием оболочки, используя тот же метод