Unix / Linux: разница между реальным идентификатором пользователя, эффективным идентификатором пользователя и сохраненным идентификатором пользователя

Мне уже известен настоящий идентификатор пользователя . Это уникальный номер пользователя в системе.

В моей системе My uidis

$ echo $UID
1014
$                 

Что обозначают два других идентификатора?
И какова польза от эффективного идентификатора пользователя и сохраненного идентификатора пользователя и где мы его используем в системе?

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

Итак, реальный идентификатор пользователя - это то, кем вы являетесь на самом деле (тот, кто владеет процессом), а эффективный идентификатор пользователя - это то, на что операционная система смотрит, чтобы принять решение, разрешено ли вам что-то делать (большую часть времени , есть исключения).

Когда вы входите в систему, оболочка входа устанавливает для реального и эффективного идентификатора пользователя одно и то же значение (ваш реальный идентификатор пользователя), указанное в файле паролей.

Теперь также случается, что вы выполняете программу setuid, и помимо работы от имени другого пользователя (например root) программа setuid также должна что-то делать от вашего имени. Как это работает?
После выполнения программы setuid у нее будет ваш настоящий идентификатор (поскольку вы являетесь владельцем процесса) и эффективный идентификатор пользователя владельца файла (например root), поскольку он равен setuid.

Программа делает все необходимое с привилегиями суперпользователя, а затем хочет что-то сделать от вашего имени. Это означает, что попытки сделать что-то, чего вы не должны делать, должны потерпеть неудачу . Как оно это делает? Ну, очевидно, изменив его эффективный идентификатор пользователя на настоящий идентификатор пользователя!

Теперь у программы setuid нет возможности переключиться обратно, поскольку ядро ​​знает только ваш идентификатор и ... ваш идентификатор . Бах, ты мертв.

Это то, для чего нужен сохраненный идентификатор пользователя.

Попробую объяснить пошагово на нескольких примерах.

Краткая предыстория

Каждый процесс имеет свои «полномочия процесса» , который включает в себя такие атрибуты , как PID, в PPID, PGID, session IDа также реальные и эффективных идентификаторы пользователей и групп: RUID, EUID, RGID, EGID.

Мы сосредоточимся на них.

Часть 1. Общие сведения о UID и GID

Теперь я войду в оболочку со своими учетными данными и запустил:

$ grep $LOGNAME /etc/passwd
rotem:x:1000:1000:rotem,,,:/home/rotem:/bin/bash

Вы можете увидеть мое имя журнала (rotem), UID и GID, которые равны 1000, и другие детали, такие как оболочка, в которую я вошел.

Часть 2: Общие сведения о RUID и RGID

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

Давайте запустим простую команду, чтобы проверить это:

$ sleep 10 & ps aux | grep 'sleep'

И проверьте UID и GID процесса:

$ stat -c "%u %g" /proc/$pid/
1000 1000

Это реальный идентификатор пользователя ( RUID) и реальный идентификатор группы ( RGID) процесса .

(*) Проверьте другие параметры, чтобы просмотреть UID и GID, а также способы их получения в виде однострочного файла .

На данный момент, принять тот факт , что EUIDи EGIDатрибуты являются «лишними» и просто равно RUIDи RGIDза кулисами.

Часть 3. Общие сведения о EUID и EGID

Возьмем pingдля примера команду.

Найдите двоичное местоположение с помощью whichкоманды, затем запустите ls -la:

-rwsr-xr-x  1 root root   64424 Mar 10  2017  ping

Вы можете видеть, что владелец и группа файла root. Это связано с тем, что pingкоманде необходимо открыть сокет, а ядро ​​Linux требует rootдля этого привилегий.

Но как я могу использовать, pingесли у меня нет rootпривилегии?
Обратите внимание на букву «s» вместо «x» в части разрешения файла, относящейся к владельцу.
Это специальный бит разрешения для определенных двоичных исполняемых файлов (например, pingи sudo), который известен как setuid .

Вот где EUIDи EGIDвступает в игру.
Что произойдет, когда будет запущен такой двоичный файл, как setuidping , процесс изменит свой эффективный идентификатор пользователя ( EUID) со значения RUIDпо умолчанию на владельца этого специального двоичного исполняемого файла, которым в данном случае является -root .
Это все благодаря тому простому факту, что этот файл имеет setuidбит.

Ядро принимает решение, имеет ли этот процесс привилегию, просматривая EUIDпроцесс. Поскольку теперь EUIDуказывает на root, операция не будет отклонена ядром.

Примечание : в последних выпусках Linux вывод pingкоманды будет выглядеть иначе из-за того, что они приняли подход возможностей Linux вместо этого подхода setuid - для тех, кто не знаком - прочтите здесь .

Часть 4: А как насчет SUID и SGID?

Сохраненный идентификатор пользователя ( SUID) используется, когда запущен привилегированный процесс ( rootнапример,), и ему необходимо выполнить некоторые непривилегированные задачи.

В этом случае эффективный UID ( EUID) из предыдущего будет сохранен внутри, SUIDа затем изменен на непривилегированную задачу. Когда непривилегированная задача будет завершена, EUIDбудет снято значение SUIDи переключится обратно на привилегированную учетную запись.