工做中遇到一個案例:備份還原事後或者對數據庫分離&附加後(移動數據庫文件),發現一些權限爲EXTERNAL_ACCESS和UNSAFE程序集對應的CLR函數,在調用的時候會出現一些錯誤。下面特地用YourSQLDba備份還原到一個測試環境,而後調用CLR函數,就會遇到以下錯誤:sql
USE YourSQLDba;
GO
SELECT *
FROM [yUtl].[clr_GetFolderList]('C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\',
'*.mdf');
Msg 10314, Level 16, State 11, Line 19數據庫
在嘗試加載程序集 ID 65537 時 Microsoft .NET Framework 出錯。服務器可能資源不足,或者不信任該程序集。請從新運行查詢,或檢查有關的文檔瞭解如何解決程序集信任問題。有關此錯誤的詳細信息: 服務器
System.IO.FileLoadException: Could not load file or assembly 'yoursqldba_clrfileop, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An error relating to security occurred. (Exception from HRESULT: 0x8013150A)app
System.IO.FileLoadException: ide
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)函數
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)測試
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)spa
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)日誌
at System.Reflection.Assembly.Load(String assemblyString)code
檢查發現assembly_id=65537的程序集爲YourSqlDba_ClrFileOp
USE YourSQLDba;
GO
SELECT a.name
,a.principal_id
,a.assembly_id
,a.clr_name
,a.permission_set_desc
,a.is_visible
,a.create_date
,a.modify_date
FROM sys.assemblies AS a
出現這種錯誤,通常是EXTERNAL_ACCESS 和UNSAFE的程序集,錯誤出現的具體緣由有兩種:
1: 數據庫Owner的SID變化了。不管你是備份還原仍是分離附加操做,都要確保數據庫全部者SID在數據庫屬性中顯示的內容與源數據庫元數據中記錄的內容之間匹配。若是使用備份/還原,則數據庫全部者SID可能不匹配(取決於你操做時使用的帳號),這將阻止CLR代碼運行。
2: 數據庫的TRUSTWORTHY屬性值變化了。 數據庫屬性TRUSTWORTHY用於指明SQL Server實例是否信任該數據庫以及其中的內容。 默認狀況下,此設置爲 OFF,可是可使用ALTER DATABASE語句將其設置爲ON.
此屬性可用於減小附加數據庫所帶來的某些隱患,該數據庫包含下列對象之一:
· 帶有 EXTERNAL_ACCESS 或 UNSAFE 權限設置的有害程序集。 有關詳細信息,請參閱 CLR Integration Security。
· 所定義的、做爲高特權用戶執行的有害模塊。 有關詳細信息,請參閱 EXECUTE AS 子句 (Transact-SQL)。
這兩種狀況均要求具備特定程度的權限,而且在已附加到SQL Server實例的數據庫的上下文中使用這兩種狀況時,應採起相應的機制保護這兩種狀況。 可是,若是數據庫脫機,則對數據庫文件具備訪問權限的用戶可能會將其附加到其選擇的SQL Server實例,並將有害內容添加到數據庫中。 在SQL Server中分離和附加數據庫時,將對限制訪問數據庫文件的數據和日誌文件設置某些權限。
由於不能當即信任附加到SQL Server實例的數據庫,因此不容許數據庫訪問超出數據庫範圍的資源,直到數據庫已顯式標記爲可信。 所以,若是備份或分離TRUSTWORTHY選項設置爲 ON 的數據庫並將該數據庫附加或還原到同一個或另外一個 SQL Server 實例後,則附加/還原完成後 TRUSTWORTHY 屬性將設置爲 OFF。 此外,旨在訪問數據庫之外資源的模塊和帶有 EXTERNAL_ACCESS 或 UNSAFE 權限設置的程序集還須要其餘條件才能成功運行。
下面檢查數據庫的屬性TRUSTWORTHY(is_trustworth_on), 以下所示
SELECT database_id ,
name ,
is_trustworthy_on
FROM sys.databases
WHERE name='YourSQLDba';
可是你對比源數據庫的屬性TRUSTWORTHY,就會發現數據庫還原後,TRUSTWORTHY屬性會變化(is_trustworth_on從1變爲了0).
設置YourSQLDba的屬性TRUSTWORTHY爲ON
USE master;
GO
ALTER DATABASE YourSQLDba SET TRUSTWORTHY ON;
還原數據庫時,因爲可能使用不一樣帳號,那麼就會出現數據庫的owner出現變化的狀況。固然,也有可能使用相同的帳號操做,不會出現db_owner變化的狀況。下面這種狀況,就是源數據庫的db_owner爲sa,可是我使用域帳號作了還原操做。數據庫的db_owner變成了一個域帳號。
USE [YourSQLDba];
GO
EXEC sp_changedbowner 'sa';
GO
將數據庫的db_owner修改成sa,此時問題解決。固然也能夠先修改db_owner,而後設置數據庫的trustworth屬性。分離附加數據庫也會致使TRUSTWORTHY屬性變化,還有可能致使數據庫db_owner變化(這個取決於你操做時使用的帳號),另外。這種錯誤只對權限爲EXTERNAL_ACCESS 和UNSAFE的程序集出現,對於SAFE_ACCESS的程序集,不會出現這個問題。
參考資料:
https://support.microsoft.com/zh-cn/help/918040/you-may-receive-an-error-message-when-you-try-to-run-an-existing-clr-o
https://docs.microsoft.com/en-us/sql/relational-databases/security/trustworthy-database-property?view=sql-server-ver15