
Ich versuche, den richtigen Grund für die gestellte Frage zu finden. Mein Verständnis ist, dass:
sudo
muss die Datei lesen/etc/sudoers
, die nur von root gelesen werden kann, weshalb sie set-UID root sein musssu
wird eine neue Shell mit einer anderen realen und effektiven UID erstellen und muss das Passwort überprüfen. Um das Passwort zu überprüfen, muss es lesen/etc/shadow
, weshalb es auf set-UID root gesetzt werden muss. Nach der Überprüfung des Passworts müsste essetuid()
den gegabelten Prozess aufrufen, und um ein beliebiges UID-Argument zu verwenden, muss sein übergeordneter Prozess root als effektive UID haben, was also noch einen weiteren Grund darstellt.
Sind die oben genannten Gründe richtig?
Antwort1
Ihre Gründe sind größtenteils richtig, aber in beiden Fällen ( su
und sudo
) besteht der Hauptgrund für die Ausführung als Root darin, dass sie die verschiedenen Benutzer- und Gruppenkennungen des aktuellen Prozesses ändern können müssen. Dies beinhaltet den Aufruf von Funktionen wiesetreuid
, die für beliebige Benutzer und Gruppen nur funktionieren, wenn der aufrufende Prozess als Root ausgeführt wird.
Sowohl su
als auch sudo
haben weitere Funktionen, die ebenfalls eine Ausführung als Root erfordern, aber im Vergleich zu den oben genannten sind das eher zweitrangige Details. Wie Sie erwähnen, sudo
muss lesen können /etc/sudoers
; aber die Tatsache, dass Letzteres nur von root gelesen werden kann, ist keine feste Voraussetzung. Beide Programme können PAM zur Authentifizierung verwenden, aber sie enthalten normalerweise auch Fallbacks, die die Fähigkeit erfordern, zu lesen /etc/shadow
, was ebenfalls nur von root gelesen werden kann. Die Liste geht noch weiter; aber das spielt keine Rolle, da die unausweichliche Tatsache ist, dass die Möglichkeit zum Ändern von Benutzern und/oder Gruppen nur root gegeben ist, weshalb su
und sudo
als Setuid-Roots fungieren.
Wie funktionieren die internen Komponenten von sudo?und die zugehörigen Fragen liefern zusätzliche Hintergrundinformationen.