Usando o método de declaração

Asserté um método que pode ser chamado em classes de permissão de acesso do código e de PermissionSet classe. Você pode usar Assert permitir que seu código (e chamadores downstream) realizar ações que seu código tem permissão para fazer, seus chamadores, mas talvez não tenha permissão para fazer. Uma declaração de segurança altera o processo normal de que o tempo de execução executa durante uma verificação de segurança. Quando você declarar uma permissão, ele informa o sistema de segurança para não verificar os chamadores do seu código para a permissão de confirmado.

Cuidado
Use declarações com cuidado, pois podem prejudicar o mecanismo do runtime para impor restrições de segurança e abrem brechas de segurança.

Declarações são úteis em situações em que uma biblioteca chama código não gerenciado ou faz uma chamada que requer uma permissão que obviamente não está relacionada ao uso pretendido da biblioteca. Por exemplo, todos gerenciados código chamadas para código não gerenciado devem ter SecurityPermission com o UnmanagedCode sinalizador especificado. Código não for proveniente de um computador local, como, por exemplo, o código que é baixado da intranet local, não receberão essa permissão por padrão. Portanto, em ordem para o código que é baixado da intranet local para poder chamar uma biblioteca que usa o código não gerenciado, ele deve ter a permissão declarada pela biblioteca. Além disso, algumas bibliotecas podem fazer chamadas que são invisíveis para chamadores e requerem permissões especiais.

Você também pode usar as declarações em situações em que o seu código acessa um recurso de forma que é completamente ocultada de chamadores. Por exemplo, suponha que sua biblioteca adquire as informações de um banco de dados, mas o processo também lê informações de registro do computador. Porque os desenvolvedores que usam a biblioteca não tem acesso à sua fonte, eles têm de nenhuma maneira de saber que seu código requer RegistryPermission para usar o seu código. Nesse caso, se você decidir que não é razoável ou necessárias para exigir que os chamadores do seu código tem permissão para acessar o registro, você pode declarar a permissão para ler o registro. Nessa situação, é apropriado para a biblioteca de declarar a permissão para isso que os chamadores sem RegistryPermission pode usar a biblioteca.

A declaração afeta a stack walk somente se a permissão de confirmado e uma permissão exigida por um chamador downstream são do mesmo tipo e a permissão exigida é um subconjunto da permissão confirmado. Por exemplo, se você declarar FileIOPermission ler todos os arquivos na unidade c e uma demanda de downstream é feita para FileIOPermission para ler os arquivos em C:\Temp, a declaração poderia afetar a stack walk; No entanto, se a demanda foi por FileIOPermission para gravar na unidade C, a declaração não tem nenhum efeito.

Para executar declarações, seu código deve ter a permissão ambos são a declarar e a SecurityPermission que representa o direito de fazer declarações. Embora você poderia declarar uma permissão que seu código não foi concedido, a declaração seria inútil porque a verificação de segurança falhará antes de causa a afirmação de que ela tenha êxito.

A ilustração a seguir mostra o que acontece quando você usa Assert. Suponha que as instruções a seguir são verdadeiras sobre assemblies, A, B, C, E e f e duas permissões P1 e P1A:

• P1A representa o direito para ler os arquivos. txt na unidade C.

• P1 representa o direito de ler todos os arquivos na unidade C.

• P1A e P1 são FileIOPermission tipos e P1A é um subconjunto de P1.

• Assemblies e e f tenham permissão P1A.

• Assembly c concedeu permissão de P1.

• Módulos (assemblies) A e b receberam permissões P1 nem P1A.

• Método a está contido no assembly A, B do método está contido no assembly b e assim por diante.

Usando o Assert

Chama nesse cenário, chamadas de método A B, C de chamadas de B, C E e e chama f. Método c declara a permissão para ler os arquivos na unidade C (permissão P1) e o método e de exige permissão para ler os arquivos. txt na unidade C (permissão P1A). Quando a demanda de f é encontrada em tempo de execução, uma stack walk é realizada para verificar as permissões de todos os chamadores de F, começando com e. E já tem permissão P1A, para que a movimentação de pilha prossegue para examinar as permissões de C, onde a declaração do c é descoberta. É porque a permissão de demanda (P1A) é um subconjunto da permissão confirmado (P1), as paradas de movimentação de pilha e a verificação de segurança automaticamente bem-sucedida. Não importa que conjuntos a e b não receberam permissão P1A. Declarando P1, o método c garante que os chamadores podem acessar o recurso protegido pelo P1, mesmo se os chamadores não receberam permissão para acessar o recurso.

Se você cria uma biblioteca de classe e uma classe acessa um recurso protegido, você deve, na maioria dos casos, fazer uma a demanda de segurança que exigem que os chamadores da classe tem a permissão apropriada. Se a classe, em seguida, executa uma operação para que você sabe que a maioria dos chamadores não terá permissão e, se você estiver disposto a aceitar a responsabilidade para permitir que esses chamadores chamar seu código, você pode declarar a permissão chamando o Assert método em um objeto de permissão que representa a operação em que o código está executando. Usando Assert dessa forma permite que os chamadores que normalmente não poderiam fazer isso chamar seu código. Portanto, se você declarar uma permissão, você deve certificar realizar verificações de segurança apropriadas antecipadamente para impedir que o seu componente mal utilizadas.

Por exemplo, suponha que sua classe biblioteca altamente confiáveis tem um método que exclui os arquivos. Ele acessa o arquivo chamando uma função não gerenciada do Win32. Um chamador chama seu código Excluir método, passando o nome do arquivo a ser excluído, C:\Test.txt. Dentro do Excluir método, o código cria um FileIOPermission objeto que representa o acesso de gravação para o C:\Test.txt. (Acesso de gravação é necessário para excluir um arquivo). Seu código chama uma verificação de segurança imperativa, chamando o FileIOPermission do objeto demanda método. Se um dos chamadores na pilha de chamadas não tiver essa permissão, um SecurityException é lançada. Se nenhuma exceção é lançada, você sabe que todos os chamadores têm o direito de acessar o C:\Test.txt. Porque você acha que a maioria dos seus chamadores não terá permissão para acessar código não gerenciado, seu código, em seguida, cria um SecurityPermission o objeto que representa o direito para chamar código não gerenciado e chama o objeto Assert método. Finalmente, ele chama a função do Win32 não gerenciada para excluir C:\Text.txt e retorna o controle ao chamador.

Cuidado

Você deve certificar-se de que seu código não usa asserções em situações onde o seu código pode ser usado por outro código para acessar um recurso protegido pela permissão que você está declarando.Por exemplo, no código que grava em um arquivo cujo nome é especificado pelo chamador como um parâmetro, você poderia não declarar a FileIOPermission para gravar em arquivos, porque o seu código deve ser aberto para uso indevido por terceiros.

Quando você usa a sintaxe de segurança imperativa, chamando o Assert método em várias permissões no mesmo método faz com que seja lançada uma exceção de segurança. Em vez disso, você deve criar um PermissionSet de objeto, passar para ele as permissões individuais que você deseja chamar e então chamar o Assert método na PermissionSet objeto. Você pode chamar o Assert método mais de uma vez quando você usa a sintaxe de segurança declarativa.

O exemplo a seguir mostra a sintaxe declarativa para verificações de segurança de substituição usando o Assert método. Observe que o FileIOPermissionAttribute sintaxe assume dois valores: um SecurityAction enumeração e o local do arquivo ou diretório ao qual permissão deve ser concedido. A chamada para Assert faz com que as demandas de acesso a C:\Log.txt para ter êxito, mesmo que os chamadores não são verificados para permissão para acessar o arquivo.

[Visual Basic]

Option Explicit
Option Strict

Imports System
Imports System.IO
Imports System.Security.Permissions

Namespace LogUtil
   Public Class Log
      Public Sub New()

      End Sub

     <FileIOPermission(SecurityAction.Assert, All := "C:\Log.txt")> Public Sub 
      MakeLog()
         Dim TextStream As New StreamWriter("C:\Log.txt")
         TextStream.WriteLine("This  Log was created on {0}", DateTime.Now) '
         TextStream.Close()
      End Sub
   End Class
End Namespace

namespace LogUtil
{
   using System;
   using System.IO;
   using System.Security.Permissions;

   public class Log
   {
      public Log()
      {    
      }   
      [FileIOPermission(SecurityAction.Assert, All = @"C:\Log.txt")]
      public void MakeLog()
      {   
         StreamWriter TextStream = new StreamWriter(@"C:\Log.txt");
         TextStream.WriteLine("This  Log was created on {0}", DateTime.Now);
         TextStream.Close();
      }
   }
} 

Os fragmentos de código a seguir mostram a sintaxe de imperativa para verificações de segurança de substituição usando o Assert método. Neste exemplo, uma instância de FileIOPermission objeto for declarado. Seu construtor é passado FileIOPermissionAccess.AllAccess definir o tipo de acesso permitido, seguido por uma seqüência de caracteres que descreve o local do arquivo. Uma vez o FileIOPermission objeto é definido, você precisará chamar seu Assert método para substituir a verificação de segurança.

[Visual Basic]

Option Explicit
Option Strict
Imports System
Imports System.IO
Imports System.Security.Permissions
Namespace LogUtil
   Public Class Log
      Public Sub New()
      End Sub 'New
      
      Public Sub MakeLog()
         Dim FilePermission As New FileIOPermission(FileIOPermissionAccess.AllAccess, "C:\Log.txt")
         FilePermission.Assert()
         Dim TextStream As New StreamWriter("C:\Log.txt")
         TextStream.WriteLine("This  Log was created on {0}", DateTime.Now)
         TextStream.Close()
      End Sub
   End Class
End Namespace 

namespace LogUtil
{
   using System;
   using System.IO;
   using System.Security.Permissions;

   public class Log
   {
      public Log()
      {    
      }   
      public void MakeLog()
      {
         FileIOPermission FilePermission = new FileIOPermission(FileIOPermissionAccess.AllAccess,@"C:\Log.txt"); 
         FilePermission.Assert();
         StreamWriter TextStream = new StreamWriter(@"C:\Log.txt");
         TextStream.WriteLine("This  Log was created on {0}", DateTime.Now);
         TextStream.Close();
      }
   }
}

Consulte também

Referência

PermissionSet

SecurityPermission

FileIOPermission

SecurityAction

Conceitos

Estendendo metadados usando atributos

Substituindo as verificações de segurança

Segurança de Acesso de código

Demandas de segurança