Edit

Share via

CLR integration programming model restrictions

  • Article

Applies to: SQL Server Azure SQL Managed Instance

When you build a managed stored procedure or other managed database object, SQL Server performs certain code checks that need to be considered. These checks are performed on the managed code assembly when first registered in the database, using the CREATE ASSEMBLY statement, and also at runtime. The managed code is also checked at runtime because in an assembly there might be code paths that might never actually be reached at runtime.

These code checks provide flexibility for registering third-party assemblies especially, so that an assembly isn't blocked where there's unsafe code designed to run in a client environment, but would never be executed in the hosted common language runtime (CLR). The requirements that the managed code must meet depend on whether the assembly is registered as SAFE, EXTERNAL_ACCESS, or UNSAFE. SAFE is the strictest security level.

In addition to restrictions being placed on the managed code assemblies, there are also code security permissions that are granted. The CLR supports a security model called code access security (CAS) for managed code. In this model, permissions are granted to assemblies based on the identity of the code. SAFE, EXTERNAL_ACCESS, and UNSAFE assemblies have different CAS permissions. For more information, see CLR Integration Code Access Security.

If the publisher policy is set, CREATE ASSEMBLY fails.

CREATE ASSEMBLY checks

When the CREATE ASSEMBLY statement runs, the following checks are performed for each security level. If any check fails, CREATE ASSEMBLY fails with an error message.

Global (any security level)

All referenced assemblies must meet one or more of the following criteria:

  • The assembly is already registered in the database.

  • The assembly is one of the supported assemblies. For more information, see Supported .NET Framework Libraries.

  • You're using CREATE ASSEMBLY FROM <location>, and all the referenced assemblies and their dependencies are available in <location>.

  • You're using CREATE ASSEMBLY FROM <bytes ...>, and all the references are specified via space separated bytes.

EXTERNAL_ACCESS

All EXTERNAL_ACCESS assemblies must meet the following criteria:

  • Static fields aren't used to store information. Read-only static fields are allowed.

  • The PEVerify test is passed. The PEVerify tool (peverify.exe), which checks that the common intermediate language (CIL) code and associated metadata meet type safety requirements, is provided with the .NET Framework SDK.

  • Synchronization, for example with the SynchronizationAttribute class, isn't used.

  • Finalizer methods aren't used.

The following custom attributes are disallowed in EXTERNAL_ACCESS assemblies:

  • 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

  • All EXTERNAL_ACCESS assembly conditions are checked.

Runtime checks

At runtime, the code assembly is checked for the following conditions. If any of these conditions are found, the managed code isn't allowed to run, and an exception is thrown.

UNSAFE

You can't load an assembly, either explicitly by calling the System.Reflection.Assembly.Load() method from a byte array, or implicitly using Reflection.Emit namespace.

EXTERNAL_ACCESS

All UNSAFE conditions are checked.

All types and methods annotated with the following host protection attribute (HPA) values in the supported list of assemblies are disallowed.

  • SelfAffectingProcessMgmt
  • SelfAffectingThreading
  • Synchronization
  • SharedState
  • ExternalProcessMgmt
  • ExternalThreading
  • SecurityInfrastructure
  • MayLeakOnAbort
  • UI

For more information about HPAs and a list of disallowed types and members in the supported assemblies, see Host Protection Attributes and CLR Integration Programming.

SAFE

All EXTERNAL_ACCESS conditions are checked.

Related content