CAS Fulltrust für Intranet
Jens Mander sein Bruder
Ich arbeite an einer Anwendung, deren Dateien auf einer Netzwerkfreigabe
liegen (Gemapptes Laufwerk Z: verweist auf einen Server-Pfad).
Beispielhaft soll folgender Code ausgeführt werden:
static void Main(string[] args) {
WebPermission wp = new WebPermission(PermissionState.Unrestricted);
if(SecurityManager.IsGranted(wp))
Console.WriteLine("WebPermission granted!");
else
Console.WriteLine("WebPermission not granted!");
}
Um in einer sauberen Umgebung zu testen, habe ich zunächst mit
"caspol -a -reset" alle Sicherheitseinstellungen zurückgesetzt.
In der .NET Framework 2.0 Konfiguration habe ich den Berechtigungssatz für
die LocalIntranet_Zone auf FullTrust gesetzt. Ich erhalte immernoch
"WebPermission not granted!". Anschließend habe ich den Berechtigungssatz
für die Wurzelebene All_Code auf FullTrust gesetzt. Ich erhalte immernoch
"WebPermission not granted!".
Zu guter Letzt habe ich auch noch CAS ausgeschaltet mit "caspol -s off". Das
führt dazu, dass die Ausführung des Programms sofort scheitert ("Das
Programm funktioniert nicht mehr"). Eine Fehlermeldung wird dabei nicht
ausgegeben. Ein WriteLine("Hallo") vor obigem Code, wird vor dem Absturz
noch ausgegeben.
Meiner Meinung nach hätte die Einstellung von FullTrust für die
LocalIntranet_Zone völlig ausreichen müssen, um meinen Assemblys auf allen
Network-Shares des Intranets Fulltrust einzuräumen. Ich verstehe nicht,
warum das nicht geschehen ist. Im Netz wird diese Frage zwar mehrfach
behandelt. Aber leider hören alle Antworten auf, bevor mein Problem
besprochen wurde.
Bin für jede Idee dankbar!
Viele Grüße
Kai Korla
WebPermission hat mit Deiner Sache nix am Hut. Ad-Hoc fällt mir
ZoneIdentityPermission ein. Kann aber auch eine andere Klasse sein. Ich les
mal MSDN nach :-)
Grüße
Kai
"Jens Mander sein Bruder" <jem...@example.com> schrieb im Newsbeitrag
news:47861191$0$25369$9b4e...@newsspool4.arcor-online.net...
Kai Korla
also ich verstehe Dein Problem jetzt so, dass Du Dateien auf'm Share hast.
Auf dieses willst Du mit Deiner Anwendung (welche von local gestartet wird)
zugreifen. Falls dies so ist, dann sollte FileIOPermission
(http://msdn2.microsoft.com/de-de/library/system.security.permissions.fileiopermission(VS.80).aspx)
das Richtige sein.
Das könnte dann ungefähr so ausschauen:
using System;
using System.Security.Permissions;
using System.IO;
namespace FileIOPermission
{
public class Program
{
[FileIOPermission(SecurityAction.Assert, All = @\\share\file.txt)]
static void Main(string[] args)
{
FileIOPermission fiop = new FileIOPermission(PermissionState.None);
FileStream fs = File.Open(@\\share\file.txt, FileMode.Open);
StreamReader sr = new StreamReader(fs);
Console.WriteLine(sr.ReadToEnd());
sr.Close();
fs.Close();
Console.ReadLine();
}
}
}
Mit SecurityAction.Assert kann man drauf zugreifen mit SecurityAction.Deny
geht es nicht.
Grüße
Kai
"Kai Korla" <kai....@contrade-consulting.de> schrieb im Newsbeitrag
news:6C679F5F-2E74-4352...@microsoft.com...
Jens Mander sein Bruder
einen Webzugriff und scheitert mit dem Fehler, dass WebPermission nicht
erteilt werden konnte. Von diesen Beispielen gibts nen ganzen Haufen. Alle
neuen Anwendungen auf dem Netzwerkpfad haben Berechtigungsprobleme. Eine
alte (sehr umfangreiche) Anwendung (mit vielen Bibliotheken im Intranet) die
ebenfalls auf dem Netzwerk entwickelt und ausgeführt wird, hat die Probleme
irgendwie nicht.
Es gibt z. B. eine Klassenbibliothek A. Ein altes Projekt, dass eben diese
Klassenbibliothek einbindet (als Projekt), hat keine Probleme deren
Fuktionen zu nutzen. Ein neues Projekt (Konsolenanwendung), dass genau diese
selbe Klassenbibliothek einbindet, scheitert sofort mit irgendeiner
beliebigen fehlenden SecurityPermission entweder beim Ausführen an der
Kommandozeile oder beim Debuggen z. B. mit dem Hinweis, dass die
Klassenbibliothek A (auch hier als Projekt eingebunden) nicht gefunden
werden konnte (wegen einer SecurityPermission). Führe ich die
Konsolenanwendung lokal aus (Bibliothek weiterhin im Netz am alten
Standort), dann läuft das. Offenbar hat die Konsolenanwendung nicht die
Berechtigung, die Assembly A einzubinden. Es geht hier nicht um die
konkreten Permissions, sondern darum, dass Anwendungen auf dem Intranet
nicht FullTrust geniessen, obwohl genau das in der Framework-Konfiguration
eingestellt wurde.
"Kai Korla" <kai....@contrade-consulting.de> schrieb im Newsbeitrag
news:6C679F5F-2E74-4352...@microsoft.com...
Jens Mander sein Bruder
Das ganze Entwicklungsprojekt inklusive .sln liegt auf dem share.
"Kai Korla" <kai....@contrade-consulting.de> schrieb im Newsbeitrag
news:82D3EDCD-A971-4AD5...@microsoft.com...
Frank Dzaebel
> Ich arbeite an einer Anwendung, deren Dateien auf einer Netzwerkfreigabe
> liegen (Gemapptes Laufwerk Z: verweist auf einen Server-Pfad).
> [...] In der .NET Framework 2.0 Konfiguration habe ich den
> Berechtigungssatz für die LocalIntranet_Zone auf FullTrust gesetzt.
ein paar Links zu dem Thema :
[SecurityException bei Zugriff über LAN]
http://dzaebel.net/Security.htm
(gerade eben ging die Seite nicht)
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Jens Mander sein Bruder
>
> [SecurityException bei Zugriff über LAN]
> http://dzaebel.net/Security.htm
Ich mache ja genau das (3.):
http://groups.google.de/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/ad5e16390d482667
Ich habe auch nicht das Gefühl, etwas falsch verstanden zu haben. Leider
funktioniert es trotzdem nicht. Um auf Nummer sicher zu gehen habe ich allen
Codegruppen den Berechtigungssatz FullTrust zugeordnet. Ich erhalte aber
stets den Fehler "Die Datei oder Assembly XXX, Version=1.0.2931.38223,
Culture=neutral, PublicKeyToken=5920149251199c95 oder eine Abhängigkeit
davon wurde nicht gefunden. Die minimale Berechtigung konnte nicht erteilt
werden. (Ausnahme von HRESULT: 0x80131417)".
Die genauen Umstände sind wie folgt:
Es gibt ein freigegebenes Verzeichnis auf einem Server (Windows Server 2003)
in unserem Firmennetzwerk (NT4-Domäne). Dieses freigegebene Verzeichnis habe
ich auf meinem Rechner (Vista64 Business) auf den Laufwerksbuchstaben Z:
gemappt. In dem freigegebenen Verzeichnis liegt ein .NET 2.0-Projekt, dass
ich mit Visual Studio 2005 bearbeite (Rechtsklick auf den Link im Startmenü
und dann "Als Administrator ausführen"). Das Projekt (z. B. eine
Windows-Anwendung) bindet weitere Projekte (Klassenbibliotheken) ein (meist
als Projekt) - u. a. auch die obige XXX-Assembly aus der Fehlermeldung. Beim
Ausführen der Windowsanwendung im Visual Studion (mit Debugger) oder an der
Kommandozeile startet das Programm zunächst, scheitert dann aber beim Aufruf
einer Funktion aus der Assembly XXX mit der genannten Fehlermeldung...
Kopiere ich die Windows-Anwendung (aber nicht die Bibliotheken - auch nicht
XXX - die bleiben alle irgendwo unter Z:) auf ein lokales Laufwerk, dann
erhalte ich keinen Fehler und alles läuft wunderbar...
Jens Mander sein Bruder
:(
Jens Mander sein Bruder
eigenen Webservice auf.
Das Testprojekt (Consolenanwendung) liegt samt Quelltext in der Intranetzone
(auf einem gemappten Laufwerk des internen Entwicklungsservers). Die
vordefinierte Codegruppe LocalIntranet_Zone auf Maschinenebene hat den
Berechtigungssatz FullTrust.
Wenn ich diese Testanwendung aus Visual Studio heraus (mit Debugger) starte,
dann erhalte ich noch vor Beginn der eigentlichen Programmasuführung eine
System.Security.SecurityException. Aktiviere ich in den
Anwendungseinstellungen unter 'Sicherheit' die
'ClickOnce-Sicherheitseinstellungen', dann kann das Programm im Debugger
ausgeführt werden. Soweit so gut. Wenn ich das Programm jetzt erstelle und
die resultierende .exe-Date an der Kommandozeile ausführen will, dann
erhalte ich wiederum eine System.Security.SecurityException mit unten
stehender Meldung.
Offenbar wurde die Assembly zur Sicherheitsüberprüfung in die richtige Zone
eingeordnet (Intranet). Leider wurde ihr jedoch nicht FullTrust gewährt,
sondern nur der unten explizit aufgeführte Berechtigungssatz. Da das Ganze
unter Vista64 ausgeführt wird, halte ich es für möglich, dass hier
Konfigurationsprobleme eine Rolle spielen.
Unbehandelte Ausnahme: System.Security.SecurityException: Fehler bei der
Anfrage.
bei
System.Security.CodeAccessSecurityEngine.ThrowSecurityException(Assembly
asm, PermissionSet granted, PermissionSet refused, RuntimeMethodHandle rmh,
SecurityAction action, Object demand, IPermission permThatFailed)
bei System.Security.CodeAccessSecurityEngine.CheckSetHelper(PermissionSet
grants, PermissionSet refused, PermissionSet demands, RuntimeMethodHandle
rmh, Object assemblyOrString, SecurityAction action, Boolean throwException)
bei
System.Security.CodeAccessSecurityEngine.CheckSetHelper(CompressedStack cs,
PermissionSet grants, PermissionSet refused, PermissionSet demands,
RuntimeMethodHandle rmh, Assembly asm, SecurityAction action)
bei TestWS.Program.Main(String[] args)
Die Aktion, bei der ein Fehler aufgetreten ist:
LinkDemand
Der Typ der ersten Berechtigung, bei der ein Fehler aufgetreten ist:
System.Security.PermissionSet
Folgendes wurde angefordert:
<PermissionSet class="System.Security.PermissionSet"
version="1"
Unrestricted="true"/>
Gew"hrter Berechtigungssatz der fehlgeschlagenen Assembly war:
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.EnvironmentPermission,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Read="USERNAME"/>
<IPermission class="System.Security.Permissions.FileDialogPermission,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Read="Z:\Web\AntragsDaten\TestWS\bin\Debug\"
PathDiscovery="Z:\Web\AntragsDaten\TestWS\bin\Debug\"/>
<IPermission
class="System.Security.Permissions.IsolatedStorageFilePermission, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Allowed="AssemblyIsolationByUser"
UserQuota="9223372036854775807"
Expiry="9223372036854775807"
Permanent="True"/>
<IPermission class="System.Security.Permissions.ReflectionPermission,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="ReflectionEmit"/>
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="Assertion, Execution, BindingRedirects"/>
<IPermission class="System.Security.Permissions.UIPermission, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.UrlIdentityPermission,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Url="file:///Z:/Web/AntragsDaten/TestWS/bin/Debug/TestWS.exe"/>
<IPermission class="System.Security.Permissions.ZoneIdentityPermission,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Zone="Intranet"/>
<IPermission class="System.Net.DnsPermission, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Drawing.Printing.PrintingPermission,
System.Drawing, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
version="1"
Level="DefaultPrinting"/>
</PermissionSet>
Die Assembly oder AppDomain, bei der ein Fehler aufgetreten ist:
TestWS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Die Zone der Assembly, bei der ein Fehler aufgetreten ist:
Intranet
Der URL der Assembly, bei der ein Fehler aufgetreten ist:
file:///Z:/Web/AntragsDaten/TestWS/bin/Debug/TestWS.exe
Jens Mander sein Bruder
existieren; eine für das 64Bit-System und eine für 32 Bit. Der erste Teil
kann mit der .NET Framwork 2.0 Konfiguration bearbeitet werden. Der
32Bit-Teil stellt leider kein grafisches Tool zur Verfügung und muss deshalb
mit dem entsprechenden Kommandozeilenprogramm bearbeitet werden
(caspol.exe). Für das 64-Bit-System und Framework 2.0 ist dies die Datei
"C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe" für das
32-Bit-System ändert sich der Pfad auf
"C:\Windows\Microsoft.NET\Framework64\v2.0.50727". Die 64 im Pfad bedeutet,
dass es sich beim Inhalt des Ordner um die 32-Bit-Versionen handelt :) (Das
ist so ähnlich wie mit SysWOW64 - Systemkonfigurationsprogramme für 32 Bit).
An der Kommandozeile (als Administrator ausführen) kann dann ganz normal die
Laufzeitsicherheitsrichtlinie für LocalIntranet auf FullTrust angehoben
werden:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\caspol -m -chggroup 1.2
FullTrust
Seit dieser Änderung funktioniert hier endlich alles wie erwartet.
Frank Dzaebel
habe gerade gesehen, dass Du Dein Problem
gelöst hast. Das hilft sicher auch anderen bzgl. Vista.
Ich werden es mal gleich in meinem Artikel mit
verlinken.
[SecurityException bei Zugriff über LAN]
http://dzaebel.net/Security.htm
-> Beachten Sie ggf. Vista64-Richtlinien.