SQL CLR组件设置为不安全的键不再工作

发布于 2025-01-24 15:30:59 字数 1131 浏览 6 评论 0原文

我在仅内部数据库和Web应用程序上运行了一个不安全的组件,但是IT部门。可能已经改变了一些事情,因为我们注意到它只是停止工作并试图弄清楚原因。

错误:

msg 10314,16级,状态11,第12行
在尝试加载汇编ID XXXXX时,Microsoft .NET框架中发生了错误。服务器可能用尽资源,或者可能不会使用clibersion_set = external_access或不安全信任程序集。再次运行查询,或检查文档以查看如何解决汇编信任问题。有关此错误的更多信息:

system.io.io.fileleloadexception:无法加载文件或组装'mytestAssembly,版本= 0.0.0.0,culture =中性,publicKeyToken = xxxxxxxxxxxxxxxxxxx'或其依赖性之一。发生与安全有关的错误。 (Hresult的例外:0xxxxxxxxa)

system.io.fileleloadexception:

at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

几个小动物/问题:

  • 上周发生了一些事情,并且刚刚开始在大会上方遇到这些错误
  • 不安全的
  • 是 知道安全性,但这只是内部)
  • .pfx密钥是否过期?
  • 我可以运行任何查询以检查所有权限以查看是否正确的权限? (我本人可能没有完全访问权限,但有人可以检查它们)
  • 我不相信它使用证书,但在过去,我们使用.pfx并具有一定的登录名来访问程序集。
  • 我相信这是在SQL Server 2012中创建的,但在SQL Server 2016上运行,现在

将不胜感激。

I have had an UNSAFE assembly running on an internal only database and web application but the IT dept. might have changed something as we noticed it just stopped working and trying to figure out why.

The error:

Msg 10314, Level 16, State 11, Line 12
An error occurred in the Microsoft .NET Framework while trying to load assembly id xxxxx. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE. Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error:

System.IO.FileLoadException: Could not load file or assembly 'mytestassembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=xXXXXXXXXXXXXx' or one of its dependencies. An error relating to security occurred. (Exception from HRESULT: 0xXXXXXXXA)

System.IO.FileLoadException:

at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

A couple of tidbits/questions:

  • Something happened in the last week and it just started getting these errors above
  • The assembly is UNSAFE because JSON.Net was added to it years ago
  • As far as I can tell via IT talks, trustworthy is ON (I know the security but this is only internal)
  • Do the .pfx keys expire?
  • Is there any query I can run to check all the permissions to see if anything is correct? (I myself might not have full access but someone can check them)
  • I don't believe it uses a certificate but in the past we use .pfx with a certain login to access the assembly.
  • I believe this was created in SQL Server 2012 but runs on SQL Server 2016 now

Any help would be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

孤独陪着我 2025-01-31 15:30:59

证书到期日的日期被模块签名忽略,尤其是用于验证(这是在此上下文中使用证书的目的,而不是签署某物)。但是,如果您不使用证书(通过将其加载到[Master]数据库中,并从该证书中创建登录名,然后将其授予不安全汇编许可) ,无论如何,这部分是无关紧要的。

以下是要开始调查的两个查询:

USE [db_name_containing_the_assembly];

SELECT db.name, db.is_trustworthy_on, db.owner_sid, USER_SID(1) AS [OwnerSID-DbLevel]
FROM   sys.databases db
WHERE  db.database_id = DB_ID();

SELECT perm.[permission_name], perm.[state_desc]
FROM   sys.server_permissions perm
WHERE perm.grantee_principal_id = <db.owner_sid from first query>;

第一个查询将:

  1. 确认启用可信赖是否可以
  2. 为您提供数据库所有者的SID(第二询问中使用)
  3. 指示是否存在不匹配的所有者SID值之间的服务器级和数据库级别之间的sid值

至少应返回以下行:

UNSAFE ASSEMBLY GRANT

基于结果:

  1. 如果trustworthy实际上设置为off,您可以将其设置为上的
  2. 如果两个SID值不相同,则可以通过Alter Alter授权修复其中一个,
  3. 如果登录不具有Unsafte汇编许可,授予它

,发生了什么事?某人:

  1. SET Trust Worthy to off
  2. 将数据库所有者更改为没有不安全汇编权限
  3. 撤销的不安全的汇编的权限。登录的权限

Certificate expiration dates are ignored by module signing, especially for validation (which is what a certificate is used for in this context, as opposed to signing something). However, if you aren't using the certificate (by loading it into the [master] database and creating a login from that certificate which is then granted the UNSAFE ASSEMBLY permission), then this part is irrelevant anyway.

Below are two queries to start investigating with:

USE [db_name_containing_the_assembly];

SELECT db.name, db.is_trustworthy_on, db.owner_sid, USER_SID(1) AS [OwnerSID-DbLevel]
FROM   sys.databases db
WHERE  db.database_id = DB_ID();

SELECT perm.[permission_name], perm.[state_desc]
FROM   sys.server_permissions perm
WHERE perm.grantee_principal_id = <db.owner_sid from first query>;

The first query will:

  1. confirm whether or not TRUSTWORTHY is enabled
  2. give you the SID of the database owner (used in the second query)
  3. indicate if there is a mismatch of owner SID values between the server-level and database-level

The second query should return at least the following row:

UNSAFE ASSEMBLY GRANT

Based on the results:

  1. If TRUSTWORTHY is actually set to OFF, you can set it to ON
  2. If the two SID values are not the same, then fix one of them via ALTER AUTHORIZATION
  3. If the login doesn't have the UNSAFE ASSEMBLY permission, grant it

So, what happened? Someone either:

  1. set TRUSTWORTHY to OFF
  2. changed the database owner to one that doesn't have the UNSAFE ASSEMBLY permission
  3. revoked the UNSAFE ASSEMBLY permission from the login
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文