Verwenden der Deny-Methode
Aktualisiert: November 2007
Das Aufrufen von Deny verhindert den Zugriff auf die Ressource, die von der verweigerten Berechtigung angegeben wird. Wenn der Code Deny aufruft und ein nachgeschalteter Aufrufer später die verweigerte Berechtigung fordert, schlägt die Sicherheitsüberprüfung fehl, selbst wenn der Aufrufer über die Berechtigung für den Zugriff auf die Ressource verfügt. Die geforderte und die verweigerte Berechtigung müssen nicht genau übereinstimmen, damit Deny wirksam wird, und die geforderte Berechtigung muss keine Teilmenge der verweigerten Berechtigung sein. Wenn die Schnittmenge der beiden Berechtigungen jedoch leer ist, diese also keine gemeinsamen Elemente haben, bleibt der Aufruf von Deny wirkungslos. Beachten Sie, dass Deny keinen tieferen Code in der Aufrufliste überschreiben kann, wenn dieser ein Assert ausführt. Wenn tieferer Code in der Aufrufliste Assert ausführt, kann der tiefere Code auf die Ressource zugreifen, die durch höheren Code in der Aufrufliste verweigert wird.
Sie können Deny im Code aufrufen lassen, um Haftungsfälle zu verhindern, da Deny dem Code den Zugriff auf die verweigerte Ressource verwehrt. Das Aufrufen von Deny verhindert jedoch keine zukünftigen Sicherheitsassertionen durch nachgeschaltete Aufrufer.
Die folgende Abbildung veranschaulicht die Vorgänge bei der Verwendung von Deny. Angenommen, die folgenden Aussagen gelten für die Assemblys A, B, C, D und E sowie für Berechtigung B1:
B1 stellt das Recht zum Lesen aller Dateien auf Laufwerk C dar.
Den Assemblys A, B, C, D und E wurde B1 erteilt.
Methode F platziert eine Forderung für Berechtigung B1.
Methode C erstellt eine Instanz der B1-Klasse und ruft anschließend die Deny-Methode von B1 auf.
Methode A ist in Assembly A enthalten, Methode B ist in Assembly B enthalten usw.
Verwenden von "Deny"
.gif "Fordern und Verweigern von Berechtigungen")
Der Aufruf von Deny durch Methode C kann sich auf die Ergebnisse von Forderungen für B1 auswirken. Angenommen, Methode A ruft B auf, B ruft C auf, C ruft E auf, und E ruft F auf. Da Methode F direkt auf die von B1 geschützte Ressource zugreift, ruft Methode F eine Sicherheitsüberprüfung für B1 durch Aufrufen der Demand-Methode von B1 (oder mithilfe einer deklarativen Forderung) auf. Diese Forderung weist die Common Language Runtime an, die Berechtigungen aller Aufrufer in der Aufrufliste zu überprüfen, wobei mit Assembly E begonnen wird. Da Assembly E die Berechtigung B1 erteilt wurde, fährt die Common Language Runtime mit der Überprüfung der Berechtigungen von Assembly C fort. Da Methode C jedoch B1 verweigert wurde, schlägt die von Methode E ausgelöste Sicherheitsüberprüfung an diesem Punkt fehl, und eine SecurityException wird ausgelöst. Die Sicherheitsüberprüfung schlägt unabhängig davon fehl, ob Assembly C und ihren Aufrufern (Assemblys A und B) B1 erteilt wurde;. Da Methode C Deny aufgerufen hat, kann Code in den Assemblys A und B nicht auf die von B1 geschützte Ressource zugreifen.
Der folgende Code veranschaulicht die deklarative Syntax zum Überschreiben von Sicherheitsüberprüfungen mithilfe der Deny-Methode. In diesem Beispiel gibt die ReflectionPermission-Syntax zwei Werte an: Eine SecurityAction-Enumeration und die Einstellung für die TypeInformation-Eigenschaft. TypeInformation wird auf true festgelegt, um anzugeben, dass diese Berechtigung das Recht darstellt, private Member durch Reflektion anzuzeigen. SecurityAction.Deny wird übergeben, um diese Berechtigung zu verweigern. Eine vollständige Liste der Werte, die angegeben werden können, finden Sie in der Beschreibung von ReflectionPermission. Mit dieser Sicherheitsdeklaration kann die Methode keine privaten Member eines Typs durch Reflektion lesen.
Option Strict
Option Explicit
Imports System
Imports System.Security.Permissions
<ReflectionPermissionAttribute(SecurityAction.Deny, TypeInformation = true ")> Public Class
MyClass1
Public Sub New()
End Sub
Public Sub GetPublicMembers ()
' Access public members through reflection.
End Sub
End Class
using System;
using System.Security.Permissions;
[ReflectionPermissionAttribute(SecurityAction.Deny, TypeInformation = true)]
public class MyClass
{
public MyClass()
{
}
public void GetPublicMembers()
{
//Access public members through reflection.
}
}
Der folgende Code veranschaulicht die imperative Syntax zum Überschreiben von Sicherheitsüberprüfungen mithilfe der Deny-Methode. In diesem Beispiel wird das ReflectionPermission-Objekt deklariert, und seinem Konstruktor wird ReflectionPermissionFlag.TypeInformation übergeben, um die aktuelle Berechtigung zu initialisieren. Wenn die Deny-Methode aufgerufen wird, können weder der Code noch die Aufrufer dazu verwendet werden, private Felder durch Reflektion zu lesen.
Option Explicit
Option Strict
Imports System
Imports System.Security.Permissions
Public Class MyClass1
Public Sub New()
End Sub
Public Sub ReadRegistry()
Dim MyPermission As New ReflectionPermission (ReflectionPermissionFlag.TypeInformation)
MyPermission.Deny()
' Access public members through reflection.
End Sub
End Class
using System;
using System.Security.Permissions;
public class MyClass {
public MyClass() {
}
public void ReadRegistry() {
ReflectionPermission MyPermission = new ReflectionPermission (ReflectionPermissionFlag.TypeInformation);
MyPermission.Deny();
// Access public members through reflection.
}
}
Kanonisierungsprobleme beim Verwenden von "Deny"
Beim Verweigern von FileIOPermission, RegistryPermission, WebPermission, UrlIdentityPermission, SiteIdentityPermission und EnvironmentPermission sollten Sie sehr vorsichtig vorgehen, da einzelne Dateien, Registrierungseinträge, URLs und Systempfade mithilfe mehrerer Namen beschrieben werden können. Beispielsweise gibt es mehrere Möglichkeiten, um auf eine einzelne Datei, MyFile.log , zu verweisen. Dazu zählen "c:\MyFile.log " und "\\MyMachineName\c$\MyFile.log ". Wenn Sie eine Berechtigung erstellen, die den Zugriff auf "c:\MyFile.log" darstellt, und dem Code dann diese Berechtigung verweigern, kann der Code u. U. weiterhin über den alternativen Pfad "\\MyMachineName\c$\MyFile.log" auf die Datei zugreifen.
Mit einer Verbindung aus PermitOnly und Deny können Sie Kanonisierungsprobleme vermeiden. PermitOnly bietet die Möglichkeit, nur einen von mehreren möglichen Namen für eine Ressource festzulegen. Außerdem wird als Nebeneffekt der Zugriff auf diese Ressource unter Verwendung anderer Namen verweigert. Nachdem Sie mit PermitOnly den einzigen zulässigen Namen für eine Ressource angegeben haben, müssen Sie mit Deny den Zugriff auf die Ressource mit diesem Namen verweigern.
Im folgenden Code wird mit einer Kombination aus Deny und PermitOnly verhindert, dass der Code auf die Ressource MyLog.log zugreift. Dieser Code sperrt außerdem den Zugriff auf die Ressource über alternative Namen oder Pfade.
<FileIOPermissionAttribute(SecurityAction.PermitOnly, All := "C:\ "), FileIOPermissionAttribute(SecurityAction.Deny, All := "C:\MyLog.log")>
[FileIOPermissionAttribute(SecurityAction.PermitOnly, All = @"C:\ ")]
[FileIOPermissionAttribute(SecurityAction.Deny, All = @"C:\MyLog.log")]
Siehe auch
Konzepte
Überschreiben von Sicherheitsüberprüfungen