SQL Server Programming and Host Protection Attributes
The ability to load and execute managed code in a SQL Server host requires meeting the host's requirements for both code access security and host resource protection. The code access security requirements are specified by one of three SQL Server permission sets: SAFE, EXTERNAL-ACCESS, or UNSAFE. Code executing within the SAFE or EXTERNAL-ACCESS permission sets must avoid certain types or members that have the HostProtectionAttribute attribute applied. The HostProtectionAttribute is not a security permission as much as a reliability guarantee in that it identifies specific code constructs, either types or methods, that the host may disallow. The use of the HostProtectionAttribute enforces a programming model that helps protect the stability of the host.
Note
Code Access Security (CAS) has been deprecated across all versions of .NET Framework and .NET. Recent versions of .NET do not honor CAS annotations and produce errors if CAS-related APIs are used. Developers should seek alternative means of accomplishing security tasks.
Host Protection Attributes
Host protection attributes identify types or members that do not fit the host programming model and represent the following increasing levels of reliability threat:
Are otherwise benign.
Could lead to destabilization of server-managed user code.
Could lead to destabilization of the server process itself.
SQL Server disallows the use of a type or member that has a HostProtectionAttribute that specifies a HostProtectionResource value of SharedState, Synchronization, MayLeakOnAbort, or ExternalProcessMgmt. This prevents the assemblies from calling members that enable sharing state, perform synchronization, might cause a resource leak on termination, or affect the integrity of the SQL Server process.
Disallowed Types and Members
The following table identifies types and members whose HostProtectionResource values are disallowed by SQL Server.
SQL Server Permission Sets
SQL Server allows users to specify the reliability requirements for code deployed into a database. When assemblies are uploaded into the database, the author of the assembly can specify one of three permission sets for that assembly: SAFE, EXTERNAL-ACCESS, or UNSAFE.
Permission set | SAFE | EXTERNAL-ACCESS | UNSAFE |
---|---|---|---|
Code access security | Execute only | Execute + access to external resources | Unrestricted |
Programming model restrictions | Yes | Yes | No restrictions |
Verifiability requirement | Yes | Yes | No |
Ability to call native code | No | No | Yes |
SAFE is the most reliable and secure mode with associated restrictions in terms of the allowed programming model. SAFE code has high reliability and security features. SAFE assemblies are given enough permission to run, perform computations, and have access to the local database. SAFE assemblies need to be verifiably type safe and are not allowed to call unmanaged code.
EXTERNAL-ACCESS provides an intermediate security option, allowing code to access resources external to the database but still having the reliability and safety of SAFE.
UNSAFE is for highly trusted code that can only be created by database administrators. This trusted code has no code access restrictions, and it can call unmanaged (native) code.
SQL Server uses the host-level code access security policy layer to set up a host policy that grants one of the three sets of permissions based on the permission set stored in SQL Server catalogs. Managed code running inside the database always gets one of these code access permission sets.
Programming Model Restrictions
The programming model for managed code in SQL Server requires functions, procedures, and types which do not require the use of state held across multiple invocations or the sharing of state across multiple user sessions. Further, as described earlier, the presence of shared state can cause critical exceptions that impact the scalability and the reliability of the application.
Given these considerations, SQL Server disallows the use of static variables and static data members. For SAFE and EXTERNAL-ACCESS assemblies, SQL Server examines the metadata of the assembly at CREATE ASSEMBLY time, and fails the creation of such assemblies if it finds the use of static data members and variables.