c# - 除非标记为UNSAFE，否则C#CLR会引发安全异常

Question

我在SQL Server 2012中有一个C＃CLR（.NET 4.5）存储过程，该存储过程是从事务内调用的。 CLR调用需要TLS 1.2的Web服务。

如果我使用permission_set = UNSAFE创建程序集，则一切正常，但我真的想避免这种情况，而是使用EXTERNAL_ACCESS。但是，这是一个真正的挑战。

使用EXTERNAL_ACCESS时有两个问题：

1）我从CLR写入一个日志文件（出于维护和调试目的），因为不允许锁，该文件不起作用：

private static readonly object Locker = new object();
public static string LogMessage(string message)
{
    message = String.Format("{0}: {1}" + Environment.NewLine, DateTime.Now, message);

    lock (Locker)
    {
        var file = new FileStream(GetConfigValue("LogFile"), FileMode.Append, FileAccess.Write);
        var sw = new StreamWriter(file);
        sw.Write(message);
        sw.Flush();
        sw.Close();
    }
    return message;
}

错误信息：


  System.Security.HostProtectionException：尝试执行CLR主机禁止的操作。
  
  受保护的资源（仅在完全信任的情况下可用）是：所有需要的资源是：同步，ExternalThreading


我可以登录到数据库表，但是由于对CLR的调用是在事务内进行的，因此错误将导致回滚，这也将回滚日志记录。我可以使用事件日志，但我真的不愿意这样做。

2）我调用的Web服务需要TLS 1.2，但不允许设置 ServerCertificateValidationCallback：

ServicePointManager.ServerCertificateValidationCallback = AcceptAllCertifications;

错误信息：


  System.Security.SecurityException：请求类型为“ System.Security.Permissions.SecurityPermission，mscorlib，Version = 4.0.0.0，Culture = neutral，PublicKeyToken = b77a5c561934e089”的权限失败。
  System.Security.SecurityException：
  在System.Security.CodeAccessSecurityEngine.Check处（对象需求，StackCrawlMark＆stackMark，布尔值isPermSet）
         在System.Security.CodeAccessPermission.Demand（）
         在System.Net.ServicePointManager.set_ServerCertificateValidationCallback（RemoteCertificateValidationCallback值）
         在AcmeClr.StoredProcedures.ProcessPayment（SqlMoney数量，SqlString ticketNo，SqlString＆resultCode，SqlString＆resultText）


无论如何，这个问题是否存在-是否可以在不使用UNSAFE的情况下进行这项工作？

Answer 1

对于问题1（使用锁来管理同时写入同一日志文件的多个线程/会话），除了UNSAFE模式之外，无法使用锁。但是，好消息是，您可能首先不需要使用锁。真正实现锁的全部目的是确保同时发生的两个LogMessage()调用不会冲突，其中一个会出错。这可以通过使用FileStream constructor的另一个重载来解决，该重载允许传入FileShare选项/枚举。您应该能够传递FileShare.ReadWrite来防止该错误。您已经将DateTime.Now连接到message中，因此，如果在较晚的消息之后写入较早的消息，这应该有助于解决序列问题。

但是，除了特定的争用之外，即使使用了锁定，您仍然会有两个会话在大致同时插入它们的消息的同时执行SQLCLR WebService存储过程的问题。您如何区分消息？我建议在存储过程的开头创建一个新的Guid并将其连接到每条消息中，以便您可以将特定调用的消息与存储过程相关联（假定您的代码在多个地方调用< cc>），并将这些消息与其他调用（无论是否并发）区分开。

如果以上两个部分（LogMessage()和将Guid连接到FileShare.ReadWrite）都不能防止错误，那么您可以忘记message选项（尽管我仍然更喜欢将其设置为FileShare因此我可以在编写文件时轻松检查文件），而不是将Guid连接到Read中，而是在文件扩展名之前将其附加到message值的末尾。然后，特定呼叫的消息会自动相互关联，并与其他并发呼叫区分开。这只是意味着您有一堆日志文件。

关于此的其他三个想法：


通过在GetConfigValue("LogFile")方法中使用lock，您实际上在增加阻塞，因为在不同会话中对该方法的并发调用将必须等待锁所有者释放锁。毕竟，这首先就是锁定点，对吗？除了处理事务外，您真的不想超出绝对必要的时间来延长它们，并且通过SQLCLR进行Web服务调用的本质是您已经在使事务依赖于网络延迟和该外部设备的响应能力。系统（即使是内部系统）。
您提到：


  我可以登录到数据库表，但是由于对CLR的调用是在事务内进行的，因此错误将导致回滚，这也将回滚日志记录。


不必要。如果使用进程内“上下文连接”，则可以，这是正确的。如果您使用常规/外部连接，或者您没有在连接字符串中指定LogMessage()关键字，或者您确实指定了Enlist，则也是如此。但是，如果指定Enlist = true;，则它应该是单独的/断开连接的事务，如果调用存储过程的事务被回滚，则不会回滚。
尽管这在使用SQLCLR代码的情况下可能无济于事，但我至少会提到，对于纯T-SQL代码，当要解决发生回滚时丢失日志记录的问题时，可以选择首先将这些记录写入表变量。表变量不受事务约束，因此回滚不会影响它们。不利的一面是，如果该进程死于某种方式，使其在到达回滚后将表变量的记录插入到真实表中的那个部分之前完全终止，那么您确实会丢失这些记录。在那儿有时最好写一个日志文件或使用SQLCLR通过Enlist = false;建立常规/外部连接。




不幸的是，对于问题2（设置Enlist = false;），您无能为力。为了支持FTPS，尝试将ServicePointManager.ServerCertificateValidationCallback属性设置为UseSSL和true时遇到了相同的问题。我还没有找到一种方法来在执行此操作时将程序集标记为FtpWebRequest。



旁注：


我同意将Assembly保留为PERMISSION_SET = UNSAFE而不是EXTERNAL_ACCESS的愿望，但是鉴于这是您的代码，并且您没有使用UNSAFE引入任何第3方库或不受支持的.NET Framework库，实际风险水平很低。
另外，希望您使用的是基于非对称密钥或证书的登录名，以允许程序集具有非UNSAFE权限，并且不将数据库设置为SAFE。
除非简化了“问题”中显示的代码以便仅发布“必需”的代码以传达当前问题，否则您将缺少围绕外部资源进行的错误处理。如果该进程崩溃，如果您未能正确处置TRUSTWORTHY ON和StreamWriter，则日志文件将被锁定，直到卸载App Domain。您可以在这5行周围添加try / finally结构，也可以让编译器使用FileStream构造/宏为您完成此操作。