代码访问安全性 - 了解SecurityTransparent可以调用SecurityCritical的原因

Question

我正在研究代码访问安全性.我需要付出一些努力来解决问题,所以我认为我最终会使用Reflector并开始研究.NET 4.0如何使用安全属性.

意见

该System.IO.File.Delete方法使用[SecuritySafeCritical]属性进行修饰.

该System.IO.File.Delete方法委托给使用该属性修饰的内部方法InternalDelete[SecurityCritical].

我在我的一个名为DeleteFile的 MVC应用程序类中有一个方法正在运行SecurityTransparent(我已经通过检查DeleteFile的MethodInfo.IsSecurityCritical属性进行了验证)

权限

根据我目前的理解,这意味着:

1. System.IO.File.Delete可以调用InternalDelete,因为[SecuritySafeCritical]方法可以调用,[SecurityCritical]因此不会抛出SecurityException.
2. DeleteFile可以调用System.IO.File.Delete因为[SecurityTransparent]可以调用[SecuritySafeCritical]

所以基本上,在不调整任何开箱即用的安全设置的情况下,此代码将成功删除名为test.txt的虚拟文件

namespace MyTestMvcApp
{
    public class FileHelpers()
    {
        // Has SecurityTransparent
        public void DeleteFile()
        {
            // Will succesfully delete the file
            File.Delete("test.txt");
        }
    }
}

混乱

在InternalDelete方法中System.IO.File.Delete,它使用该CodeAccessPermission.Demand方法检查堆栈中的所有调用者是否具有必要的权限.我不太明白的是MSDN文档中的这一行CodeAccessPermission.Demand:

不检查调用此方法的代码的权限; 检查从该代码的直接调用者开始并继续向上移动.

所以我的问题是,如果我的应用程序的DeleteFile方法是SecurityTransparent,如何允许调用SecurityCritical方法？

这可能是一个破旧的例子,或许有一些缺失的概念,但正如我所说,我仍然在理解它,任何洞察力的人都可以给予更多我将发展我的理解.

谢谢

Answer 1

您混淆了两种 CAS 执行机制。虽然他们确实有一些互动，但与您似乎担心的方式并不完全相同。就需求所代表的完全许可需求而言，它们本质上是独立的。

CLR 在执行代码之前应用透明度验证。如果通过，CLR 将验证通过属性应用的任何声明性 CAS 要求。如果这些通过（或不存在），CLR 将执行代码，此时命令式（内联）需求将运行。

Demand 文档中有关“不检查调用此方法的代码的权限”的说明适用于 Demand 方法本身。换句话说，如果您有一个调用 Demand 的方法 Foo，则经过验证的调用堆栈将从 Foo 的调用方启动，而不是 Foo 本身。例如，如果您有调用链A -> B -> C -> Foo -> Demand，则只会验证 A、B 和 C，以检查它们是否具有授予的权限。