Restrições do modelo de programação da Integração CLR

  • Artigo

Aplica-se a:SQL ServerInstância Gerenciada de SQL do Azure

Quando você está criando um procedimento armazenado gerenciado ou outro objeto de banco de dados gerenciado, há determinadas verificações de código executadas por SQL Server que precisam ser consideradas. SQL Server executa verificações no assembly de código gerenciado quando ele é registrado pela primeira vez no banco de dados, usando a instrução CREATE ASSEMBLY e também em runtime. O código gerenciado também é verificado em runtime porque, em um assembly, talvez haja caminhos de código que jamais possam ser alcançados em runtime. Isso proporciona flexibilidade para registrar, especialmente, assemblies de terceiros, logo um assembly não seria bloqueado quando houvesse um código 'não seguro' projetado para execução em um ambiente do cliente, mas que jamais seria executado no CLR hospedado. Os requisitos que o código gerenciado deve atender dependem se o assembly está registrado como SAFE, EXTERNAL_ACCESS ou UNSAFE, SAFE sendo o mais estrito e estão listados abaixo.

Além das restrições colocadas nos assemblies de código gerenciado, também há permissões de segurança de código que são concedidas. O CLR (Common Language Runtime) oferece suporte a um modelo de segurança chamado segurança de acesso do código (CAS) destinado ao código gerenciado. Nesse modelo, são concedidas permissões a assemblies com base na identidade do código. Os assemblies SAFE, EXTERNAL_ACCESS e UNSAFE têm permissões CAS diferentes. Para obter mais informações, consulte Segurança de acesso ao código de integração CLR.

Verificações de CREATE ASSEMBLY

Quando a instrução CREATE ASSEMBLY é executada, as verificações a seguir são executadas para cada nível de segurança. Se algum marcar falhar, CREATE ASSEMBLY falhará com uma mensagem de erro.

Global (qualquer nível de segurança)

Todos os assemblies referenciados devem atender a um ou mais dos seguintes critérios:

  • O assembly já está registrado no banco de dados.

  • O assembly é um daqueles para os quais há suporte. Para obter mais informações, consulte Bibliotecas de .NET Framework com suporte.

  • Você está usando olocal> CREATE ASSEMBLY FROM< e todos os assemblies referenciados e suas dependências estão disponíveis no <local>.

  • Você está usando CREATE ASSEMBLY FROM<bytes ...>, e todas as referências são especificadas por meio de bytes separados por espaço.

EXTERNAL_ACCESS

Todos os assemblies EXTERNAL_ACCESS devem atender aos seguintes critérios:

  • Não são usados campos estáticos para armazenar informações. São permitidos campos estáticos somente leitura.

  • O teste PEVerify passou. A ferramenta PEVerify (peverify.exe), que verifica se o código MSIL e os metadados associados atendem aos requisitos de segurança do tipo, é fornecida com o SDK do .NET Framework.

  • A sincronização, por exemplo, com a classe SynchronizationAttribute , não é usada.

  • Não são usados métodos Finalizer.

Os seguintes atributos personalizados não são permitidos em assemblies EXTERNAL_ACCESS :

  • System.ContextStaticAttribute

  • System.MTAThreadAttribute

  • System.Runtime.CompilerServices.MethodImplAttribute

  • System.Runtime.CompilerServices.CompilationRelaxationsAttribute

  • System.Runtime.Remoting.Contexts.ContextAttribute

  • System.Runtime.Remoting.Contexts.SynchronizationAttribute

  • System.Runtime.InteropServices.DllImportAttribute

  • System.Security.Permissions.CodeAccessSecurityAttribute

  • System.Security.SuppressUnmanagedCodeSecurityAttribute

  • System.Security.UnverifiableCodeAttribute

  • System.STAThreadAttribute

  • System.ThreadStaticAttribute

SAFE

  • Todas as EXTERNAL_ACCESS condições de assembly são verificadas.

Verificações de runtime

Em runtime, o assembly do código é verificado em relação às seguintes condições. Se alguma dessas condições for encontrada, o código gerenciado não terá permissão de execução, e uma exceção será lançada.

UNSAFE

Carregar um assembly explicitamente chamando o método System.Reflection.Assembly.Load() de uma matriz de bytes ou implicitamente por meio do uso de Reflection.Emit namespace-não é permitido.

EXTERNAL_ACCESS

Todas as condições UNSAFE são verificadas.

São desaprovados todos os tipos e métodos anotados com os seguintes valores HPA (atributo de proteção de host) na lista de assemblies para a qual há suporte.

  • SelfAffectingProcessMgmt

  • SelfAffectingThreading

  • Synchronization

  • SharedState

  • ExternalProcessMgmt

  • ExternalThreading

  • SecurityInfrastructure

  • MayLeakOnAbort

  • Interface do usuário

Para obter mais informações sobre HPAs e uma lista de tipos e membros não permitidos nos assemblies com suporte, consulte Atributos de proteção de host e Programação de integração clr.

SAFE

Todas as EXTERNAL_ACCESS condições são verificadas.

Consulte Também

Bibliotecas do .NET Framework compatíveis
Segurança de acesso a código da integração CLR
Atributos de proteção de host e programação da Integração CLR
Criando um assembly