我已经投入研究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();
错误:
为什么将SQL CLR触发器代码视为透明代码并部分受信任?
如何使SQL CLR触发器代码不是透明代码,或使其完全受信任成为?
我愿意提出建议。
最佳答案
默认情况下,SQL Server内部运行的CLR代码(即“SQLCLR”)受到严格限制,以免降低SQL Server的安全性或稳定性。
程序集中的CLR代码可以执行的操作(主要)由每个程序集的PERMISSION_SET
属性控制。如果在通过PERMISSION_SET
加载程序集时未指定CREATE ASSEMBLY
,则默认值为SAFE
,它是最受限制且不受完全信任的。为了使CLR代码能够到达SQL Server外部(到达网络,文件系统,OS等),您需要将Assembly至少设置为EXTERNAL_ACCESS
,但这仍然不是完全受信任的。为了被视为完全受信任的,您需要将Assembly设置为UNSAFE
。
为了将任何Assembly设置为EXTERNAL_ACCESS
或UNSAFE
,您需要执行以下操作之一:
UNSAFE ASSEMBLY
权限。这是首选方法。 TRUSTWORTHY = ON
。假定数据库的所有者具有UNSAFE ASSEMBLY
服务器级别的权限(通常是这种情况)。尽管此选项更快/更容易,但由于TRUSTWORTHY = ON
是fairly wide-open security hole而不是首选。 如果您想更详细地了解SQLCLR安全性,尤其是有关
SAFE
程序集的受限制程度,请查看我在SQL Server Central上编写的article。关于c# - SQL CLR触发器,由于透明代码调用关键代码,如何使程序集受信任?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/24153370/