Policy.setPolicy() 似乎无法正常工作

Question

我想通过定义我自己的扩展 Policy 类的类来设置自定义 Policy，如下所示：

public class MyPolicy extends Policy {

    public MyPolicy() {
        super();
    }

    @Override
    public PermissionCollection getPermissions(ProtectionDomain domain) {
        // return PermissionCollection with no permissions
        PermissionCollection pc = new PermissionCollection();
        return pm;
    }
}

然后，在我的应用程序开始时，我设置了我的自定义 Policy 类，我还启用了 SecurityManager 以便新策略生效：

Policy.setPolicy(new MyPolicy());
System.setSecurityManager(new SecurityManager());

上面的问题是它不起作用。上述示例的想法是引入一个策略，该策略将阻止应用程序执行任何需要任何类型许可的操作。因此，例如，当我的应用程序执行时：

System.getenv();

我希望上述结果会导致AccessControlException 应该由SecurityManager 抛出。相反，我的应用程序运行得很好。但是，当我按如下方式初始化 Policy 和 SecurityManager 时：

// setting the policy twice intentionally 
Policy.setPolicy(new MyPolicy());
Policy.setPolicy(new MyPolicy());
System.setSecurityManager(new SecurityManager());

然后执行System.getenv() 实际上会产生预期的AccessControlException。

以下是我想要解释的问题/疑虑：

• 为什么在设置 SecurityManager 后必须设置两次 Policy 才能使 Policy 生效？
• 是上面的问题是某种错误还是 Policy 类故意设计成这样（如果是，为什么？）？

Answer 1

当部分实现本身可能不受信任时，处理基于堆栈检查的安全机制会出现“有趣”的问题。使用引导类实现时要容易得多，因为 null 类加载器绕过了检查。

当你第一次setPolicy 时，Policy 实现的ProtectionDomain 被赋予所有权限。所以你所有的代码都是有特权的——不是你想要的。

对于随后的setPolicy 调用，之前的Policy 提供Policy 实现ProtectionDomain 的权限。在您的情况下，这会导致您的所有代码都拥有空的 PermissionCollection 权限。 （你可能应该在这个讨厌的 API 上调用 setReadOnly。它也是一个抽象类，所以不应该编译。）

因此，您可能希望使用单独的类加载器来加载您的不受信任的代码和您的安全机制。

只有你可能已经通过假设没有任何权限而破坏了很多东西。引导类因其null 类加载器而获得通过。例如，加载类可能需要权限，因此您不想拒绝那里的所有内容。

使用正常的策略文件配置来配置策略要好得多。