我已经投入研究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_ACCESSUNSAFE,您需要执行以下操作之一:

  • 用密码签名大会,从大会创建一个非对称 key ,从非对称 key 创建一个登录名,向该登录授予UNSAFE ASSEMBLY权限。这是首选方法。
  • 将包含程序集的数据库设置为TRUSTWORTHY = ON。假定数据库的所有者具有UNSAFE ASSEMBLY服务器级别的权限(通常是这种情况)。尽管此选项更快/更容易,但由于TRUSTWORTHY = ONfairly wide-open security hole而不是首选。

  • 如果您想更详细地了解SQLCLR安全性,尤其是有关SAFE程序集的受限制程度,请查看我在SQL Server Central上编写的article

    关于c# - SQL CLR触发器,由于透明代码调用关键代码,如何使程序集受信任?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/24153370/

    10-10 18:18
    查看更多