Is it bad to use WITH PERMISSION_SET = UNSAFE for an assembly in SQL 2005?

问题

I need to use SQLCLR to make a stored procedure that uses stuff in .NET 3.5. If I don't use PERMISSION_SET = UNSAFE I can't do it, it will just die and give me this error:

Deploy error SQL01268: .Net SqlClient
Data Provider: Msg 6503, Level 16, State 12, Line 1
Assembly 'system.core, version=3.5.0.0, culture=neutral, publickeytoken=b77a5c561934e089.' was not found in the SQL catalog.
An error occurred while the batch was being executed.

So I found this article:

http://weblogs.asp.net/paulomorgado/archive/2009/06/13/playing-with-sql-server-clr-integration-part-iv-deploying-to-sql-server-2005.aspx

And the last line says this:

"Now the DBAs won’t definitely let me use this, but it was fun to build it."

I am not sure if he was referring to the permissions being set to "unsafe".

So, can some huge gaping hole happen if you do this?

回答1:

There are three different permission_set options which restrict what the assembly can do

SAFE - Restricts the assembly to managed code

EXTERNAL_ACCESS - allows access to files, network resources, etc..

UNSAFE - Unrestricted access - including the execution of non-managed code

MSDN docs give the following guidance

Specifying UNSAFE enables the code in the assembly complete freedom to perform operations in the SQL Server process space that can potentially compromise the robustness of SQL Server. UNSAFE assemblies can also potentially subvert the security system of either SQL Server or the common language runtime. UNSAFE permissions should be granted only to highly trusted assemblies.

If your assembly only uses features of .NET 3.5, i don't see why it would need UNSAFE access.

It's possible you are using one of the types or members disallowed from the System.Core library. Microsoft has a list of these. Disallowed Types and Members in System.Core.dll

There is some more info here. Host Protection Attributes and CLR Integration Programming

回答2:

The accepted answer is correct regarding the three security levels, but incorrect regarding the reason that UNSAFE is being required here.

There are actually two questions being asked:

Is it safe to set assemblies to PERMISSION_SET = UNSAFE ?

Regardless of what some folks will gripe about, there is nothing inherently wrong or "unsafe" with the UNSAFE security level. The UNSAFE permission set does allow one to do things that can more easily compromise a systems security and/or stability, but nothing says that all functionality deemed "unsafe" would have either effect. And, poorly written queries / stored procedures / functions can adversely affect system performance and stability. Just because a feature can be abused does not mean that it cannot be used correctly to do awesome things.

SQL Server's CLR host, which is separate from the main Windows OS CLR host (and both are, or should be, separate from the ASP.NET CLR host) is highly restricted and they only included a small subset of the .NET Framework. The libraries that are included (and can be found here: Supported .NET Framework Libraries) are guaranteed to work across updates of SQL Server and updates to the .NET Framework at the server level (i.e. patches, upgrades, etc). There are other libraries that are not on that list that are completely "safe" to use in terms of what they do, but by simply not being on that "supported" list, they need to be registered as UNSAFE because they haven't been tested and are not guaranteed to remain usable across .NET Framework updates. For example, ServiceModel, I believe, was a pure MSIL library in .NET 2 and 3. However, it became mixed-mode (i.e. contains some unmanaged code) starting in .NET 4 and since SQL Server 2012 and newer are linked to only CLR v4, web services code written again ServiceModel and that worked perfectly fine in SQL Server versions prior to version 2012, stopped working starting with version 2012.
Why do I get an error mentioning system.core if I don't set the assembly to PERMISSION_SET = UNSAFE?

This issue is specific to SQL Server 2005. SQL Server 2005 was the first version to include support for .NET functionality (i.e. SQLCLR). The System.Core library did not exist in .NET Framework 2.0, and .NET Framework 3.0 was not released until late 2006 (please see: .NET Framework version history). Due to this timing, System.Core could not have been included in the CLR host for SQL Server 2005. But, due to .NET 3.0 and 3.5 using CLR v2, just like .NET Framework 2.0, it is possible to use that functionality in SQL Server 2005 IF you set the assembly to UNSAFE, which allows for looking outside of SQL Server's internal CLR host.

SQL Server 2008 and 2008 R2 both include the .NET Framework 3.5 in their internal CLR host, and they added two more libraries to the "Supported" list, one being System.Core. So, for those two versions you can use functionality from System.Core in a SAFE assembly. And, this is why System.Core is at the bottom of the "Supported .NET Framework Libraries" list (linked above).

For more info on .NET nuances related to SQLCLR, please see my article, Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server), and the whole "Stairway to SQLCLR" series on SQL Server Central.

For more info on working with SQLCLR in general, please visit: SQLCLR Info