我已经潜入研究SQL CLR。不幸的是,我的第一个示例存在透明代码调用安全代码的问题。
重点是我的SQL CLR触发器被视为透明代码。在触发器中,我使用Quartz来调用Quartz Windows服务:
var properties = new NameValueCollection();
properties["quartz.scheduler.instanceName"] = "ServerScheduler";
properties["quartz.scheduler.proxy"] = "true";
properties["quartz.scheduler.proxy.address"] = string.Format("tcp://{0}:{1}/{2}", "localhost", "555",
"QuartzScheduler");
var schedulerFactory = new StdSchedulerFactory(properties);
IScheduler scheduler = schedulerFactory.GetScheduler();
错误:
(135,1):SQL72014:.Net SqlClient数据提供者:Msg 6522,Level 16, 状态1,过程AfterMarketSessionInserted,第1行.NET Framework 执行用户定义的例程或聚合期间发生错误 " AfterMarketSessionInserted":System.MethodAccessException:尝试 通过安全透明方法 ' .Database.Triggers.MarketSessionTriggers.AfterMarketSessionInserted()' 访问安全关键方法 ' Quartz.Impl.StdSchedulerFactory..ctor(System.Collections.Specialized.NameValueCollection)' 的失败。
Assembly'数据库,版本= 1.0.5275.15169,文化=中立, 公钥=空'部分信任,导致CLR 无论透明度如何,都要使其完全透明 程序集本身的注释。 为了访问安全性 关键代码,必须完全信任此程序集。 System.MethodAccessException:at Database.Triggers.FinancialMarketSessionTriggers.AfterFinancialMarketSessionInserted()
--------------
为什么SQL CLR触发器代码被视为透明代码并且部分受信任?
如何使SQL CLR触发器代码不是透明代码或使其受信任完全?
我愿意接受建议。
答案 0 :(得分:5)
为什么SQLCLR代码仅部分受信任?
默认情况下,在SQL Server内部运行的CLR代码(即" SQLCLR")受到严格限制,以免降低SQL Server的安全性或稳定性。
如何让SQLCLR完全信任?
程序集中的CLR代码可以执行的操作(主要)由每个程序集的PERMISSION_SET
属性控制。如果您在通过PERMISSION_SET
加载大会时未指定CREATE ASSEMBLY
,则默认值为SAFE
,其中受限制最多且不完全信任。为了使CLR代码能够到达SQL Server外部(到网络,文件系统,操作系统等),您需要将程序集设置为至少EXTERNAL_ACCESS
,但这仍然不是<强>完全信任。要被视为完全信任,您需要将程序集设置为UNSAFE
。
要将任何程序集设置为EXTERNAL_ACCESS
或UNSAFE
,您需要执行以下操作之一:
UNSAFE ASSEMBLY
服务器级权限(通常是这种情况)。虽然这个选项更快/更容易,但由于TRUSTWORTHY = ON是一个相当开放的安全漏洞,因此不是首选。UNSAFE ASSEMBLY
权限。这是首选方法。如果您想更详细地了解SQLCLR安全性,特别是与SAFE程序集的限制有关,请查看我在SQL Server Central上编写的article(需要免费注册才能阅读该网站上的文章)。
答案 1 :(得分:0)
一些其他信息:如果您选择签署程序集的首选方法并创建非对称密钥,请参阅此MSDN article
下面的SQL代码段来自上述文章。在master数据库中创建密钥并登录:
update
然后创建程序集:
update