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。相反，我的应用程序运行正常。但是，当我初始化策略和SecurityManager时，如下所示：

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

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

以下是我的问题/疑虑，我希望得到解释：

为什么我必须设置两次策略以使策略在设置SecurityManager后生效？
上面是否存在某种错误，或者策略类是故意设计成这样的行为（如果是这样 - 为什么？）？

Answer 1

有趣的＆＃34;当部分实现本身可能不受信任时，处理基于堆栈检查的安全机制的问题。使用引导类实现它时会更容易，因为null类加载器会绕过检查。

第一次setPolicy时，ProtectionDomain实施的Policy将获得所有权限。所以你的所有代码都是特权 - 而不是你想要的。

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

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

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

使用常规策略文件配置配置策略要好得多。

Policy.setPolicy（）似乎无法正常工作

1 个答案: