Ich habe auch mal davon gelesen, habe allerdings kein System gefunden, auf dem das tatsaechlich funktioniert. Welche Unix-Variante hast Du denn genau? Edit: Solaris 8, wie Du oben ueberlesenerweise schriebst.

Die in dem Zitat angesprochene Race-Condition ist folgende: Wenn ein Set-UID-Script gestartet wird, muesste der Kernel zunächst den Interpreter privilegiert starten (Der Schritt vom Script zum Interpreter (ueber das Shebang)) und ihm als Parameter den Scriptnamen geben. Der Interpreter wird dann das Script oeffnen (das ist der Schritt wieder zurueck: vom Interpreter zum Script). Das koennte jetzt inzwischen aber ein anderes Script sein, welches gar nicht mehr das sid-Bit gesetzt hat.

Man koennte nun meinen, dass dieses Problem nicht nur fuer Setuid-Scripte gilt. Doch sollte man sich folgendes Szenario vor Augen halten: Ich lege in meinem Home-Verzeichnis einen Hardlink auf ein Setuid-Root-Script an, starte es ueber "./script" und sofort danach ersetze ich es durch ein beliebig böswilliges Script meiner Wahl. Mit diesem Mittel kann ich mein beliebiges Script mit Root-Rechten ausfuehren.

Die Loesung dafuer ist simpel: Der Interpreter muss das Script nicht selbst ueber einen vertrauensunwuerdigen Dateinamen oeffnen. Stattdessen wird die Datei kernelintern geoeffnet (z. B. als Deskriptor 4), und der Interpreter bekommt den Dateinamen "/dev/fd/4" als Parameter, womit es auf diesen Dateideskriptor zugreifen kann. Zwischen dem Oeffnen der Datei und dem privilegierten Ausfuehren des Interpreters kann nun ohne Race-Condition die Richtigkeit des Setuid-Bits ueberprueft werden.

/dev/fd ist unter Linux normalerweise ein Symlink auf /proc/self/fd, wobei /proc/self ein Symlink auf das aktuelle Prozess-Verzeichnis in /proc ist, z. B. /proc/43134. In dem fd-Verzeichnis ist fuer jeden offenen Dateideskriptor ein etwas magischer Symlink. Wenn man ihn oeffnet, passiert wohl ungefaehr so etwas wie bei dem dup-Systemcall (siehe dup(2)).\n\n

<!--EDIT|betterworld|1149980351-->