簡單概述SQLCLR CAS權限集
我們將詳細地討論關于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權限集代碼，以后還會深入細致的講解，請關注。
【編輯推薦】
