Какой компонент занимается авторизацией в многопользовательских режимах linux?

Если совсем упростить, то у каждого процесса обязательно есть UID (идентификатор пользователя) и GID (идентификатор группы), а у файлов, в свою очередь, есть атрибуты, в которые записываются UID и GID владельца файлов, а так же атрибуты u, g и o, которые устанавливают режим доступа для владельца, владеющей группы и всех остальных соответственно. Когда процесс пытается обратиться к файлу, ядро проверяет, совпадает ли UID или GID со значениями а атрибутах файла, а так же, вычисляет итоговый режим доступа, и если все хорошо, то процесс получает желаемое.

В однопользовательском же режиме все процессы принудительно имеют нулевой UID и GID, т.е. работают под рутом.

А если углубляться, то там еще posix acl есть, и всякие системы мандатного доступа, типа apparmor и т.д.

Выполнил «strace sudo echo sometext» и вот что нашел на выходе:

open("/etc/security/pam_env.conf", O_RDONLY) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=2972, ...}) = 0
read(8, "#\n# This is the configuration fi"..., 4096) = 2972
read(8, "", 4096)                       = 0
close(8)                                = 0
open("/etc/environment", O_RDONLY)      = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=96, ...}) = 0
read(8, "PATH=\"/usr/local/sbin:/usr/local"..., 4096) = 96
read(8, "", 4096)                       = 0
close(8)                                = 0
open("/etc/security/pam_env.conf", O_RDONLY) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=2972, ...}) = 0
read(8, "#\n# This is the configuration fi"..., 4096) = 2972
read(8, "", 4096)                       = 0
close(8)                                = 0
open("/etc/default/locale", O_RDONLY)   = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=74, ...}) = 0
read(8, "#  File generated by update-loca"..., 4096) = 74
read(8, "", 4096)                       = 0
close(8)                                = 0
open("/etc/login.defs", O_RDONLY)       = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=10551, ...}) = 0
read(8, "#\n# /etc/login.defs - Configurat"..., 4096) = 4096
read(8, " issuing \n# the \"mesg y\" command"..., 4096) = 4096
close(8)                                = 0
open("/etc/login.defs", O_RDONLY)       = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=10551, ...}) = 0
read(8, "#\n# /etc/login.defs - Configurat"..., 4096) = 4096
read(8, " issuing \n# the \"mesg y\" command"..., 4096) = 4096
close(8)                                = 0
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 8
lseek(8, 0, SEEK_CUR)                   = 0
fstat(8, {st_mode=S_IFREG|0644, st_size=2332, ...}) = 0

Загуглил по PAM. Это ведь разделяемые библиотеки для аутентификации. Тоесть для повышения привилегий процессу необходимо обратится к процессу с root, а тот в свою очередь примет решение на основании результата выполнения pam.

Еще вопрос по /etc/passwd: зачем для каждого пользователя указывать путь к интерпретатору? С этим файлом ведь работает ядро (зачем ядру знать, какой шелл использует пользователь?)? Как эти данные будут использоваться далее?

Эти данные используются при запуске сессии пользователя, у разных юзеров могут быть разные шеллы, внезапно. А некоторым не положен в принципе.

Суть в том, что грубо говоря, ядро ничего не знает про пользователей, у него есть только uid и gid для каждого процесса.
PAM, login, su и прочие утилиты это всего лишь программы, которые позволяют запустить процесс с определенными uid и gid.

Помимо u,g,o у файлов также есть атрибут «setuid» (ну и соотв. «setgid»). Они выставляют EUID равный владельцу (и/или группе) файла при запуске (не работает на скриптах).

Так вот, все бинарники типа sudo, su, login принадлежат root и имеют setuid. Т.е. они с самого начала запускаются от root (EUID=0) и потом просто запрашивают у остальных компонентов аутентификацию. Если последняя проходит успешно — происходит exec*() с EUID=0, если нет — программа (т.е. напр. sudo) аварийно завершается.

ядро ведь не должно этим заниматся? Этот модуль получает системные вызовы open?

Должно и занимается. Для ядра конечно нет никаких пользователей, есть процессы и у процессов есть uid/gid. Отображением имён пользователей на uid/gid конечно занимается не ядро, а системные утилиты, в первую очередь PAM. Например при логине из консоли пользователь вводит имя/пароль и программа login получает через PAM uid/gid соответствующий этому пользователю после чего понижает привилегии до этих id и запускает (т.о. от имени этого пользователя) шелл (т.е. процесс) с этими uid/gid. Дальше, всё что пользователь будет запускать из шелла тоже будет иметь такие uid/gid. Изменить uid/gid для запускаемой программы пользователь может только запустив программу с SUID/SGID битом, но сам установить этот бит пользователь не может (т.е. он не может так изменить свои привилегии).

Поигрался с точками входа, а именно: нашел, кто открыл tty1, и завершил найденые процессы; после этого запустил bash на tty2 с перенаправлением всего в tty1 и... все понял... Дальше поиск по старшему номеру tty1 показал, что ввод и вывод в tty обеспечивает ядро...ок.

Принцып работы login и его роль в системе стали для меня чуть понятнее...

Однако остался вопрос: = я заметил, что gdm запускается на tty1 независимо от иксов; а иксы запускаются после вхда в систему на tty7. Выходит, что графическое окно входа работает без иксов?

Графика это просто процесс, можно запускать как хочешь, на любой тту.

о...видимо надо разбирать графические режимы.