现在，我们将更为详细地讨论关于CAS的问题。但是，请记住，现在我们所讨论的许可权问题并不是在SQL Server内部的那种，而是在外部-在操作系统中的许可权。例如，比方说SQLCLR代码不得不打开一个磁盘文件来记录一些日志数据，或进行连接以从另一个数据库读取数据。CAS许可权限制代码能够存取该磁盘文件的方式以及到其它数据库的连接方式。
为了运行某种方法，无论何时CLR装载一个程序集，它都要收集关于该程序集的与在该机器上定义的策略相匹配的证据以便授予其相应的许可权。典型地，对于.NET程序集的证据通常包括位置（原始）数据（程序集从这里运行）和身份数据。但是，既然一个SQLCLR程序集从SQL Server内部运行，那么，位置证据基本上是不相关的。这样以来，只剩下了身份证据，例如是否该程序集拥有一个强名字或者是经过一家特定公司进行数字签名的。
 图3.来自四种策略级别的CAS许可权的交集 |
CLR收集该证据，然后与四种策略级别（企业，机器，用户和AppDomain）加以比较。(SQL Server文档经常调用AppDomain级别"Host Policy"，但这是一回事。在.NET框架中，AppDomain是更为典型的术语，我经常使用它)。由CLR授予给一个程序集的实际的许可权集是在每一个级别上授予的许可权的交集。
图3展示了这一工作机理。这四种级别中的每一种都有其自己的许可权集合。为了决定授予给一个程序集的许可权集，CLR使用这些许可权的交集-也即是，各种许可权集的公共集合，并且把这个交集授予给该程序集。
你可以使用.NET框架2.0配置工具来分析前三种策略级别：企业，机器和用户。图4展示了这个工具，当你展开TreeView控件的运行时刻安全策略部分时显示策略级别。
 图4.该图显示了.NET框架2.0配置工具的策略级别。 |
在此，一个用户或系统管理员能够修改显示的级别的默认策略，这样以来，一个程序集在其加载时就拥有更多或更少的许可权。这可能是个比较复杂的主题，但是对于SQLCLR代码来说，事实上，所有的安装在本地机器上的.NET代码，这三种策略级别默认地都把"完全信任"指派给一个程序集。"完全信任"仅仅意味着，代码自动地拥有每一种可能的权限。更精确地说，它意味着，CLR并不进行任何权限检查。
如果程序集默认地拥有检查"短路"的许可权，那么为什么我建议你读取所有关于CAS的内容呢？
 图5.这里是SQLCLR代码中的实际的CAS权限集。 |
理由是，CLR共使用四种策略级来指派许可权，但是只有其中三种能够使用如图４所示的工具来进行配置。第四种是AppDomain级别，该级别是当你把一个程序集安装到一个数据库时创建的。该策略级别由SQL Server控制作为CLR宿主。而且，SQL Server极少会授予一个程序集完全许可权信任，因为这对于安全性和可靠性都可能意味着极度的冒险。
图5显示出默认情况下在SQLCLR代码所发生的实际情况（记住，一个用户或系统管理员都能够修改企业、机器和用户级上的策略设置，此时，情况与图3所示相同)。因为企业、机器和用户策略级别都授予完全信任权限，他们具有相同的结果权限集-所有的许可权。该权限集与AppDomain权限集相交的结果就是程序集许可权集。
2/2 首页 上一页 1 2 |
