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