Разница между владельцем / root и RUID / EUID

25

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

Когда нам дают разрешения для файла, они выглядят так:

-rwsr-xr-- 1 user1 users 190 Oct 12 14:23 file.bin

Мы предполагаем, что пользователь, user2который находится в группе, usersпытается выполнить file.bin. Если бы бит setuid не был установлен, это означало бы, что и RUID, и EUID file.binбыли равны UID user2. Но поскольку бит setuid установлен, это означает, что RUID теперь равен UID user2, а EUID - это UID владельца файла user1.

Мои вопросы:

  1. В чем разница между владельцем файла и root? Имеет ли rootте же разрешения, что и владелец? Или нам нужна отдельная запись в списке разрешений для root?
  2. Разница между RUID и EUID?
    • Насколько я понимаю, RUID и EUID применяются только к процессам. Если это так, то почему они имеют значение идентификатора пользователя?
    • Если RUID - это пользователь, который создает процесс, а EUID - это пользователь, который в данный момент запускает процесс, то первое предложение первого ответа в этом вопросе не имеет для меня никакого смысла.
    • Правильно ли я понял, что делает бит setuid?
files permissions process root setuid user1956190
источник

Ответы:

36

Вот ответы:

  1. rootвсегда имеет полный доступ к файлам и каталогам. У владельца файла они тоже обычно есть, но это не всегда так. Например:

    -r-xr----- 1 user1 users 199 Oct 14 18:42 otherfile.bin

    user1является владельцем ; однако они могут только читать и выполнять , но rootвсе еще имеют полный доступ ( rwx ) к файлу.

  2. RUID - это реальный идентификатор пользователя, и он никогда (почти) не меняется. Если user2вход в систему, то оболочка запускается с реальным идентификатором, установленным на user2. Все процессы, которые они запускают из оболочки, будут наследовать реальный идентификатор user2как свой реальный идентификатор.

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

    Если user2выполняется file.bin, будет RUID user2и EUID запущенного процесса user1.

Давайте использовать случай passwd:

-rwsr-xr-x 1 root root 45396 may 25  2012 /usr/bin/passwd

  • Когда user2хочет сменить пароль , они исполняются /usr/bin/passwd.

  • RUID будет, user2но EUID этого процесса будет root.

  • user2может использовать passwdдля изменения только свой собственный пароль, потому что внутренне passwdпроверяет RUID и, если это не так root, его действия будут ограничены реальным паролем пользователя.

  • Необходимо, чтобы EUID стал rootв случае, passwdпотому что процесс должен писать в /etc/passwdи / или /etc/shadow.

jcbermu
источник
Спасибо! Теперь все становится понятнее. У меня есть еще один вопрос. EUID изменяется только тогда, когда пользователь выполняет процесс с установленным битом setuid? Или это может измениться и в другой ситуации? И если да, то что это за ситуация?
user1956190
1
Я думаю, что нет другого пути, кроме выполнения процессов, у которых установлен setuidбит.
jcbermu
3
Процесс, который выполняется из программы «setuid» (т. Е. Процесс, имеющий действующий UID ≠ реальный UID), может вернуть EUID обратно в RUID. В некоторых случаях он может переключать EUID назад и вперед между его начальным значением (т. Е. Владельцем файла программы) и RUID. Кроме того, он может установить свой RUID равным EUID. … (Продолжение)
Скотт
2
(Продолжение) ... Привилегированные процессы (те с EUID = 0, иначе root) можно установить EUID и RUID на произвольные значения (например, login, su, и sudoпрограммы делают это). Как правило, когда привилегированный процесс меняет свои UID на ненулевые значения, он больше не является привилегированным и не может стать rootснова. См. Справочные страницы setuid (2) , seteuid (2) и setreuid (2) .
Скотт
1
(Продолжение)… Он был введен как хак для решения одной проблемы, которая впоследствии была решена в более широком смысле. Возможно, он был удален из Linux, за исключением того факта, что такая обрезка сломала бы программы, которые его используют. Майкл Керриск, автор «Интерфейса программирования Linux» , говорит, что в своей версии справочной страницы setfsuid (2) «в setfsuid()настоящее время не требуется и ее следует избегать в новых приложениях».
Скотт