在SQL 2005中使用WITH PERMISSION_SET = UNSAFE进行程序集是不是很糟糕?

时间:2010-07-09 00:38:05

标签: c# .net sql-server sql-server-2005 sqlclr

我需要使用SQLCLR来创建一个使用.NET 3.5中的东西的存储过程。如果我不使用PERMISSION_SET = UNSAFE我不能这样做,它就会死掉并给我这个错误:

  

部署错误SQL01268:.Net SqlClient
  数据提供者:消息6503,级别16,状态12,行1   程序集'system.core,version = 3.5.0.0,culture = neutral,publickeytoken = b77a5c561934e089。'在SQL目录中找不到。
  批处理执行时发生错误。

所以我找到了这篇文章:

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

最后一行说明了这一点:

  

“现在DBA肯定不会让我使用它,但构建它很有趣。”

我不确定他是否将权限设置为“不安全”。

那么,如果你这样做,会发生一些巨大的漏洞吗?

3 个答案:

答案 0 :(得分:5)

有三种不同的permission_set选项限制程序集可以执行的操作

SAFE - 将程序集限制为托管代码

EXTERNAL_ACCESS - 允许访问文件,网络资源等。

UNSAFE - 无限制访问 - 包括执行非托管代码

MSDN文档提供以下指导

  

指定UNSAFE可以使程序集中的代码完全自由地在SQL Server进程空间中执行可能会损害SQL Server健壮性的操作。 UNSAFE程序集还可能破坏SQL Server或公共语言运行库的安全系统。 UNSAFE权限只应授予高度可信的程序集。

如果您的程序集仅使用.NET 3.5的功能,我不明白为什么它需要UNSAFE访问。

您可能正在使用System.Core库中不允许的类型或成员之一。微软有这些列表。 Disallowed Types and Members in System.Core.dll

这里有更多信息。 Host Protection Attributes and CLR Integration Programming

答案 1 :(得分:0)

关于三个安全级别,可接受的答案是正确的,但是对于此处需要UNSAFE的原因,答案是错误的。

实际上要问两个问题:

  1.   

    将程序集设置为PERMISSION_SET = UNSAFE是否安全?

    不管某些人会苦恼什么,对于UNSAFE安全级别来说,没有什么天生的错误或“不安全”。 UNSAFE权限集的确允许用户执行 更容易危及系统安全性和/或稳定性的事情,但没有任何内容表明 all 功能被视为“不安全”。会产生任何影响。而且,写得不好的查询/存储过程/功能可能会对系统性能和稳定性产生不利影响。仅仅因为功能会被滥用并不意味着它不能正确地用于完成出色的工作。

    SQL Server的CLR主机与主要的Windows OS CLR主机分离(并且两者都应该或应该与ASP.NET CLR主机分离),并且受到严格限制,并且它们仅包含.NET的一小部分框架。保证所包含的库(可以在此处找到:Supported .NET Framework Libraries)可以在SQL Server更新和服务器级别的.NET Framework更新(例如补丁,升级等)中工作。还有一些不在此列表中的库在其工作方面完全是“安全的”使用,但是由于根本不在该“受支持”列表中,因此需要将它们注册为UNSAFE,因为它们没有经过测试,也没有保证在所有.NET Framework更新中仍然可用。例如,我相信ServiceModel是.NET 2和3中的纯MSIL库。但是,从.NET 4开始,从SQL Server 2012和更高版本开始,它就变成了混合模式(即包含一些非托管代码)。仅链接到CLR v4,网络服务代码再次ServiceModel,并且在2012版之前的SQL Server版本中运行良好,从2012版开始停止工作。

  2.   

    如果我将程序集设置为PERMISSION_SET = UNSAFE,为什么会出现提及 system.core 的错误消息?

    此问题特定于SQL Server2005。SQLServer 2005是第一个包含对.NET功能(即SQLCLR)的支持的版本。 System.Core 库在.NET Framework 2.0中不存在,并且.NET Framework 3.0直到2006年下半年才发布(请参阅:.NET Framework version history)。由于此时间安排, System.Core 可能无法包含在SQL Server 2005的CLR主机中。但是,由于使用CLR v2的.NET 3.0和3.5,就像.NET Framework 2.0一样,它可以在SQL Server 2005 IF 中使用该功能,将程序集设置为UNSAFE,从而可以在SQL Server的内部CLR主机之外查看。

    SQL Server 2008和2008 R2都在其内部CLR主机中包括.NET Framework 3.5,并且在“受支持”列表中又添加了两个库,其中一个是 System.Core 。因此,对于这两个版本,您可以 SAFE程序集中使用 System.Core 中的功能。并且,这就是 System.Core 在“支持的.NET Framework库”列表(位于上面的链接)的底部的原因。

有关与SQLCLR相关的.NET细微差别的更多信息,请参阅我的文章Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server),以及有关SQL Server Central的整个“ Stairway to SQLCLR”系列文章。

有关一般使用SQLCLR的更多信息,请访问:SQLCLR Info

答案 2 :(得分:-3)

很抱歉要说明这一点,但“UNSAFE”的哪一部分难以理解?

你可以:

  • 销毁您的SQL Server和操作系统安装
  • 介绍内存泄漏
  • 添加不稳定性

我认为与你的问题"How to make this CLR work with 2005?"有关,你想使用可能产生后两种副作用的方法......