Announcement

Collapse
No announcement yet.

Security Exception in IEExec.exe

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Security Exception in IEExec.exe

    Hallo!

    Ich habe folgendes Problem:

    Meine SmartClient Applikation (derzeit ein einfaches Hello World in C#) endet in einer Security Exception in IEExec wenn ich ihn von meinem Apache WebServer starte. Das ganze passiert allerdings nur dann, wenn ich die Sicherheitseinstellungen auf NoTrust in der .Net Framework Konfiguration heruntergesetzt habe. Ab Low Trust funktioniert die Applikation.

    Falls jemand von Euch schon einmal auf dieses/ähnliches Problem gestoßen ist, wäre es nett, wenn ihr mir hier weiterhelfen könntet. Die applikation soll nie in einer Exception enden. Irgendwie muss es doch möglich sein, diese abzufangen..??
    Ich habe gelesen, dass ab dem Framework 2.0 diese Exceptions automatisch abgefangen werden. 2.0 ist aber leider noch beta und daher nicht akzeptabel. Hat jemand eine Ahnung wann die Release zu haben ist?

    Meine Konfiguration:
    Windows 2k Pro
    .Net Framework 1.1
    Visual Studio .Net 2003

    Danke schon mal für Eure Hilfe!!

    Robert

  • #2
    Hallo,
    das geschilderte Verhalten entspricht den Regeln der .NET Security. Ich zitiere im Folgenden einen Artikel aus dem dot.net magzin zu diesem Thema (3-teilige Reihe beginnend mit der Ausgabe 06.2003):
    <br>
    "Jede verwaltete Anwendung wird von der CLR im Kontext eines so genannten Hosts ausgeführt, der als vertrauenswürdiger Teil für das Starten der CLR und das Festlegen der Bedingungen zuständig ist. Nachdem der Host initialisiert wurde, kann die Assembly geladen werden, danach übernimmt die CLR die Kontrolle, um diese Anwendung auszuführen. Intern übergibt die CLR die Kontrolle nach dem Laden der Assembly zuerst an den <b>Policy Manager</b>, einem der Kernbestandteile des Sicherheitssystems von .NET. Sein Job ist es festzulegen, welche Berechtigungen dem ausführbaren Code zugeordnet werden sollen.
    Der Policy Manager übergibt die Kontrolle nur dann an den Class Loader, wenn die von der Assembly angeforderten Berechtigungen (Minimum Permission Request) zugewiesen werden können und wenn die Assembly das Recht zur Ausführung (SecurityPermissionFlag.Execution) hat, anderenfalls löst er eine Exception vom Typ PolicyException aus. Wenn der Policy Manager kein Veto eingelegt hat, sorgt der Class Loader dafür, dass die einzelnen Klassen einer Assembly bei Bedarf im Speicher als Methodentabelle und Datenstruktur abgebildet werden, wobei der Class Loader auch die Sichtbarkeitsregeln für Klassen und Interfaces prüft. Wenn das erledigt ist, übernimmt der Just-In-Time (JIT) Compiler und Type-safety Verifier die Kontrolle, indem die Methoden der Klasse erst bei Bedarf überprüft und übersetzt werden. Alle diese Bestandteile bereiten die Ausführungsumgebung vor, bei der Ausführung der Anwendung sorgt das Execution-Time Permission Enforcement über die ausgelösten Stack Walks dafür, dass die Regeln jederzeit eingehalten werden.
    Wenn Sie sich die Abbildung 2 anschauen und das soeben gelesene Revue passieren lassen, wird deutlich, dass die CLR gleich an <b>zwei</b> Stellen ein <b>Sicherheitsveto</b> einlegen kann. Zum einen kann diese Exception sofort beim Programmstart ausgelöst werden, aber zum anderen müssen Sie auch damit rechnen, dass die Exception erst beim Aufruf einer bestimmten Funktion ausgelöst wird. Immer dann, wenn die CLR erkennt, dass mit hoher Wahrscheinlichkeit der zweite Fall eintreten könnte, zeigt sie sofort beim Programmstart ein Tooltip-Fenster mit einer entsprechenden Hinweismeldung an. Der Anwender ist somit vorgewarnt, dass ein Dritter (der Administrator des Active Directory beziehungsweise des Rechners) die Sicherheitsregeln so geändert hat, dass nicht mehr jeder Aufruf auch garantiert von Erfolg gekrönt wird.
    <br>
    &gt;Die applikation soll nie in einer Exception enden...
    Die Anwendung wird im Worst-Case ja gar nicht erst gestartet, sondern der Class Loader bricht den Vorgang mit einem Sicherheits-Veto ab. Der richtige Weg besteht darin, auf dem Rechner eine neue <b>Code Group</b> anzulegen, die alle mit diesem Strong Name (*.snk) signierten Assemblies mit der höheren Berechtigung ausstattet. Wenn dieser Schritt gemacht wird, unterscheidet sich das Verhalten von .NET bei den eigenen (signierten) Assemblies nicht von früher.
    <br>
    &gt;..dass ab dem Framework 2.0 ...
    Mit <b>ClickOnce</b> steht nur ein bequemer Mechanismus zur Verfügung, über den die Regeln unabhängig vom Entwickler auch wirklich umgesetzt werden.
    &#10

    Comment

    Working...
    X