Różnica między właścicielem / rootem a RUID / EUID


25

Jestem stosunkowo nowy w stosunku do pojęć wymienionych w pytaniu, a czytanie o nich z różnych źródeł tylko je bardziej zagmatwa. Oto co rozumiałem do tej pory:

Gdy otrzymujemy uprawnienia do pliku, wyglądają one następująco:

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

Zakładamy, że użytkownik user2należący do grupy userspróbuje wykonać polecenie file.bin. Jeśli bit setuid nie został ustawiony, oznaczałoby to, że zarówno RUID, jak i EUID file.binbyły równe UID user2. Ale ponieważ setuid bit jest ustawiony, oznacza to, że RUID jest teraz równa UID user2, natomiast EUID jest UID właściciela pliku user1.

Moje pytania to:

  1. Jaka jest różnica między właścicielem pliku a root? Czy rootma takie same uprawnienia jak właściciel? A może potrzebujemy osobnego wpisu na liście uprawnień root?
  2. Różnica między RUID a EUID?
    • W moim rozumieniu RUID i EUID są stosowane tylko do procesów. Jeśli tak, to dlaczego mają wartość identyfikatora użytkownika?
    • Jeśli RUID jest użytkownikiem, który tworzy proces, a EUID jest użytkownikiem, który aktualnie uruchamia proces, to pierwsze zdanie pierwszej odpowiedzi w tym pytaniu nie ma dla mnie żadnego sensu.
    • Czy dobrze zrozumiałem, co robi bit setuid?

Odpowiedzi:


36

Oto odpowiedzi:

  1. rootma zawsze pełny dostęp do plików i katalogów. Właściciel pliku zwykle je też ma, ale nie zawsze tak jest. Na przykład:

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

    user1jest właścicielem ; mogą jednak tylko czytać i wykonywać , ale rootnadal mają pełny dostęp ( rwx ) do pliku.

  2. RUID jest prawdziwym identyfikatorem użytkownika i nigdy (prawie) się nie zmienia. Jeśli user2zalogujesz się do systemu, powłoka zostanie uruchomiona z ustawionym rzeczywistym ID user2. Wszystkie procesy, które rozpoczynają od powłoki, odziedziczą prawdziwy identyfikator user2jako ich prawdziwy identyfikator.

    EUID jest efektywnym identyfikatorem użytkownika , zmienia się dla procesów (nie dla użytkownika), które wykonuje użytkownik, który ustawił bit setuid .

    Jeśli user2sporządzi file.binThe RUID będzie user2i EUID procesu rozpoczęto będzie user1.

Użyjmy przypadku passwd:

-rwsr-xr-x 1 root root 45396 may 25  2012 /usr/bin/passwd
  • Kiedy user2chcą zmienić swoje hasło , wykonują /usr/bin/passwd.

  • RUID będzie, user2ale EUID tego procesu będzie root.

  • user2może użyć passwddo zmiany tylko własnego hasła, ponieważ wewnętrznie passwdsprawdza RUID, a jeśli nie jest root, jego działania będą ograniczone do prawdziwego hasła użytkownika.

  • Konieczne jest, aby EUID stał się rootw przypadku, passwdponieważ proces musi pisać do /etc/passwdi / lub /etc/shadow.


Dziękuję Ci! Teraz wszystko jest wyraźniejsze. Mam jeszcze jedno pytanie. EUID zmienia się tylko wtedy, gdy użytkownik wykonuje proces z ustawionym bitem setuid? Czy może to zmienić także w innej sytuacji? A jeśli tak, to jaka jest ta sytuacja?
user1956190

1
Myślę, że nie ma innego sposobu niż wykonywanie procesów, które mają setuidustawiony bit.
jcbermu

3
Proces uruchamiany z programu „setuid” (tj. Proces z efektywnym UID ≠ Rzeczywistym UID) może przywrócić EUID z powrotem do RUID. W niektórych przypadkach może przełączać EUID tam iz powrotem między jego wartością początkową (tj. Właścicielem pliku programu) a RUID. Ponadto może być w stanie ustawić swój identyfikator RUID na równy z identyfikatorem EUID. … (Ciąg dalszy)
Scott

2
(Ciąg dalszy) ... procesy uprzywilejowane (te z euid = 0, aka root) można ustawić euid i RUID do dowolnych wartości (na przykład login, sui sudoprogramy zrobić). Zasadniczo, gdy uprzywilejowany proces zmieni swoje UID na wartości niezerowe, nie jest już uprzywilejowany i nie może zostać rootponownie. Zobacz strony man setuid (2) , seteuid (2) i setreuid (2) .
Scott

1
(Ciąg dalszy)… Został wprowadzony jako hack w celu rozwiązania jednego problemu, który następnie został rozwiązany w szerszy sposób. Być może został on usunięty z systemu Linux, z wyjątkiem faktu, że takie przycinanie zepsułoby programy, które go używają. Michael Kerrisk, autor The Linux Programming Interface , mówi w swojej wersji strony podręcznika setfsuid (2)setfsuid()jest obecnie niepotrzebny i należy go unikać w nowych aplikacjach”
Scott,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.