Guten Morgen!
Aha: Mal wieder unser Lieblingsthema. Und wieder kommen die gleichen nicht realisierbaren Ideen wie vor einigen Monaten auf.
On Thu, Feb 22, 2001 at 07:58:16PM +0100, Josef Spillner wrote:
Das mit den beliebigen Prozessen sehe ich mittlerweile auch von dieser Seite her. Rein theoretisch kann man aber hier Abhilfe schaffen, wenn ein root-Daemon (von dem optimistischerweise angenommen wird daß er stabil läuft) alle Prozesse beobachtet und über ihr Verhalten Buch führt. Tanzt einer aus der Reihe wird er gekillt.
Es ist eben theoretisch *nicht* möglich, den "bösen" als solchen zu finden und ggf. zu killen. Weil eben dein "Tanzt einer aus der Reihe"-Prozess *nicht* deterministisch zu ermitteln ist. Wäre das der Fall, würde ja kein Mensch mehr über dieses Themea reden.
Es ist eben gerade der Witz der Sache, das knapper Speicher in unixoiden Systemen ein Problem ist. Du hast nun zwei Möglichkeiten: 1. du schmeisst das komplette Unix-Konzept in die Tonne 2. du sorgst dafür, dass es zu diesen Speicherengpässen nur sehr, sehr, sehr, ... selten kommt. (das bedeutet: ohne Böswilligkeit eines Nutzers im praktischen Betrieb nie)
1. funktioniert super, verursacht aber einige Probleme an anderen Stellen :) 2. machen alle anderen mir bekannten Unixe außer Linux sehr erfolgreich (ich meine hier Linux bis v2.2, zu v2.4 kann ich mich mangels Ahnung nicht äußern)
Leider ist auch das nicht so einfach:
- Prozessorlast: Dann kann man kein "make" mehr eingeben.
- Speicherverbrauch: Dann kann man den gimp keine großen Bilder mehr öffnen
lassen.
Quark. Nur weil ein Prozess 99% CPU frisst oder 2 GByte gross ist, ist er noch lange nicht böse und damit potentielles Opfer eines kills.
Deswegen muß so ein Tool schon im Userspace als Ergänzung laufen, damit man es konfigurieren kann. Meinetwegen erst "allow" und dann "deny", d.h. alles was nicht soll darf auch nicht. Beispiel: order allow,deny allow gimp mem=512M allow gcc1 proc=90% deny the ugly rest
Wie willst du auf einem solchen System in C programmierte Programe sicher ablaufen lassen? Angenommen du rufst eine Funktion auf (return-Adresse und Parameter landen auf dem Stack) wodurch just in diesem Moment eine neue Seite benötigt wird und der Prozess sein mem-Limit überschreitet. Der Prozess würde in dem Moment gekillt ohne daß der Autor des Programms irgendeine Chance hat, diesen Fall abzufangen. => System völlig unbrauchbar
Ein System mit starren Mem-Limits funktioniert nur, wenn du darauf Programmiersprachen verwendest, die *keinerlei* automatische Speicherallokation benötigen. D.h. du musst entweder allen Speicher explizit besorgen und testen (wie malloc in C) oder einen Exception-Mechanismus erfinden, der bei mem=alle anschlägt und dir sagt, wie weit dein Programm noch funktioniert hat. Beides ist in einer klassischen Unix+C-Umgebung unmöglich.
Wenn das Ziel ein *theoretisch sicheres System* sein soll (ich brauche sowas nicht), ist Unix einfach broken by Design. Unix+C wurden aber nicht mit diesem Ziel entwickelt.
Reinhard