Usando o método Deny
De chamadaDeny impede o acesso ao recurso especificado pela permissão negada. Se seu código chama Negar e um chamador downstream subseqüentemente exige a permissão negada, a verificação de segurança falhará, mesmo que todos os chamadores tem permissão para acessar o recurso.A permissão que está sendo solicitada e a permissão de negação não precisam coincidir exatamente para o Negar efeito e a permissão usados desse sistema operacional não precisa ser um subconjunto da permissão negada.No entanto, se a interseção de duas permissões está vazia (isto é, se eles possuem nada em comum), a telefonar para Negar só terá efeito.Observe que Negar não é possível substituir o código mais profundo no telefonar pilha que executa um Declarar.Se mais de código no telefonar pilha executa um Declarar, o código mais profundo pode acessar o recurso que código superior no telefonar nega a pilha.
Você pode usar chamadas de Negar em seu código para se proteger contra responsabilidade porque Negar torna impossível para o seu código para ser usado para acessar o negado recurso.No entanto, a telefonar para Negar não bloqueia a asserção de segurança no futuro por chamadores downstream.
A ilustração a seguir mostra o que acontece quando você usar Negar.Considere que as seguintes instruções são verdadeiras sobre assemblies A, B, C, D e E e permissão P1:
P1 representa o direito de ler todos os arquivos na unidade C.
Os assemblies A, B, C, D e E foram concedidos P1.
Método F coloca uma demanda na permissão P1.
Método C cria uma instância da classe P1 e, em seguida, chama Negar método.
Método A está contido no assembly A, B método está contido no conjunto B e assim por diante.
Usando negar
.gif)
telefonar do método C Negar pode afetar o resultado das demandas por P1.Por exemplo, suponha que chamadas de um método B, B chama C, C chama de chamadas E e E f.Porque o método F acessa diretamente o recurso que protege o P1, o método F invoca uma verificação de segurança para P1 chamando Por solicitação método (ou usando uma demanda declarativa).Essa demanda faz com que o tempo de execução verificar as permissões de todos os chamadores na pilha de chamadas, começando com assembly e.Porque o assembly E foi concedido permissão P1, o tempo de execução prosseguirá para examinar as permissões do assembly C.Mas, como o método C negou P1, a verificação de segurança chamada por falha de método E nesse ponto e um SecurityException é lançada. Não importa se o assembly C e seus chamadores (assemblies A e B) receberam P1; a verificação de segurança ainda falhar.Porque o método C chamado Negar, o código em módulos (assemblies) A e B não pode acessar recursos protegidos pelo P1.
O código a seguir mostra a sintaxe declarativa para a substituição de verificações de segurança usando o Negar método.Neste exemplo, a ReflectionPermission sintaxe especifica dois valores: a SecurityAction enumeração e a configuração para o TypeInformationpropriedade .TypeInformation é definida como true para especificar que essa permissão representa o direito de exibir particular membros por meio de reflexão e SecurityAction.Deny é passado para negar essa permissão.Consulte a descrição de ReflectionPermission Para obter uma lista completa de valores, você pode especificar. Com essa declaração de segurança, o método não é possível ler particular membros de um tipo por meio de reflexão.
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.
}
}
O código a seguir mostra a sintaxe fundamental para a substituição de verificações de segurança usando o Negar método.Neste exemplo, a ReflectionPermission objeto for declarado e seu construtor é passado ReflectionPermissionFlag.TypeInformation para inicializar a permissão corrente.Quando o Negar método é chamado, o código e chamadores nunca podem ser usados para ler campos privados por meio de reflexão.
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.
}
}
Problemas de canonização usando negar
Você deve ser extremamente cuidadoso ao negando FileIOPermission, RegistryPermission, WebPermission, UrlIdentityPermission, SiteIdentityPermission, e EnvironmentPermission como arquivos individuais, as entradas do registro, URLs e caminhos de sistema podem ser descritos usando vários nomes. Por exemplo, um único arquivo MyFile.log, pode ser referenciada várias maneiras, incluindo "c:\MyFile.log" e "\\MyMachineName\c$\MyFile.log".Se você cria uma permissão que representa o acesso à "c:\MyFile.log" e, em seguida, negar essa permissão a seu código, seu código ainda poderá acessar o arquivo usando o caminho alternativo "\\MyMachineName\c$\MyFile.log".
Você pode usar uma combinação de PermitOnly and Negar para evitar problemas de canonização.PermitOnly lhe dá a capacidade de especificar somente um dos vários nomes possíveis para um recurso e tem o efeito colateral de negar acesso a esse recurso usando qualquer Outros nome.Depois de usar PermitOnly para especificar o nome permitido um para um recurso, você deve usar Negar para não permitir o acesso ao recurso usando esse nome.
O código a seguir usa uma combinação de Negar and PermitOnly para impedir que seu código acessar um recurso chamado MyLog.log. Esse código também bloqueia o acesso para o recurso usando todos os caminhos ou nomes alternativos.
<FileIOPermissionAttribute(SecurityAction.PermitOnly, All := "C:\ "), FileIOPermissionAttribute(SecurityAction.Deny, All := "C:\MyLog.log")>
[FileIOPermissionAttribute(SecurityAction.PermitOnly, All = @"C:\ ")]
[FileIOPermissionAttribute(SecurityAction.Deny, All = @"C:\MyLog.log")]
Consulte também
Conceitos
Substituindo verificações de segurança