Почему этот, казалось бы, эквивалентный код SecurityManager вызывает ложные исключения?

Question

Этот вопрос является продолжением моего предыдущего вопроса о необычных исключениях, сгенерированных пользовательским менеджером безопасности. На высоком уровне я заинтересован в создании приложения, которое выполняет доверенный код вместе с ненадежным кодом. Моей первоначальной идеей было создать кастом SecurityManager это запретило бы запуск большинства операций. Это привело к необычному поведению, когда доверяющий рефлексивный код создавал ненадежные объекты после 16 вызовов.

Я переписал код так, чтобы вместо использования пользовательских SecurityManager чтобы справиться с этим, я вместо этого создаю новый домен защиты, в котором выполняется недоверенный код, а затем удаляю разрешения из этого ненадежного кода. Этот новый код показан здесь:

import java.io.FilePermission;
import java.lang.reflect.*;
import java.security.*;

public class Main {
    /* Track how many instances have been created so that we can see when the exception
     * is thrown.
     */
    private static int numInstances = 0;
    public Main() {
        System.out.println("Number created: " + ++numInstances);
    }

    /* Utility function that returns a Constructor object for main. */
    private static Constructor<Main> getCtor() {
        try {
            return Main.class.getConstructor();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
            System.exit(-1);
            return null; // Unreachable, needed to appease compiler.
        }
    }

    /* Utility function that creates an AccessControlContext that only has file
     * read permissions.
     */
    private static AccessControlContext getContext() {
        CodeSource c = new CodeSource(null, (java.security.cert.Certificate[])null);
        Permissions permissions = new Permissions();

        /* Grant specific permission to read files. This is necessary, since otherwise the
         * class loader can't read classes from disk.
         */
        permissions.add(new FilePermission("*", "read"));

        /* Construct an AccessControlContext from these permissions. */
        return new AccessControlContext(new ProtectionDomain[] {new ProtectionDomain(c, permissions)});
    }

    public static void main(String[] args) {
        /* Get a very restrictive AccessControlContext that does not allow for anything to run. */
        AccessControlContext noPermissions = getContext();

        /* Install a standard security manager to enable security. */
        System.setSecurityManager(new SecurityManager());

        /* Sit in an infinite loop using reflection to create Main objects.  This code is
         * run in a context where its only permissions are file reading.
         */
        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            @Override
            public Void run() {
                /* Continuously create new Main objects. */
                Constructor<Main> ctor = getCtor();
                try {
                    while (true) {
                        ctor.newInstance();
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                    return null;
                }
            }
        }, noPermissions);

    }
}

Этот код теперь прекрасно работает - он создает все виды Main объекты без каких-либо проблем вообще.

Что меня смущает, так это следующее. Для того, чтобы AccessController чтобы иметь какие-то зубы, нам нужно включить охранника. Я делаю это по телефону

/* Install a standard security manager to enable security. */
System.setSecurityManager(new SecurityManager());

Теперь предположим, что я изменил это по умолчанию SecurityManager к этому обычаю SecurityManager:

/* Install a standard security manager to enable security. */
System.setSecurityManager(new SecurityManager() {
    @Override
    public void checkPermission(Permission p) {
         /* Log the permission. */
         System.out.println("Checking " + p);
         super.checkPermission(p);
    }
});

это SecurityManager идентично предыдущему, за исключением того, что он регистрирует, что происходит при проверке разрешения, а затем перенаправляет запрос по умолчанию SecurityManager,

Если я внесу это изменение и запущу программу, то получу то же поведение, что и раньше:

Checking ("java.io.FilePermission" "/home/keith/Documents/secret-eclipse-workspace/Security Manager Test/bin/Main$2.class" "read")
Checking ("java.io.FilePermission" "/home/keith/Documents/secret-eclipse-workspace/Security Manager Test/bin/Main$2.class" "read")
Checking ("java.io.FilePermission" "/home/keith/Documents/secret-eclipse-workspace/Security Manager Test/bin/Main$2.class" "read")
Number created: 1
Number created: 2
Number created: 3
Number created: 4
Number created: 5
Number created: 6
Number created: 7
Number created: 8
Number created: 9
Number created: 10
Number created: 11
Number created: 12
Number created: 13
Number created: 14
Number created: 15
Checking ("java.lang.RuntimePermission" "createClassLoader")
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "createClassLoader")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
    at java.security.AccessController.checkPermission(AccessController.java:559)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at Main$1.checkPermission(Main.java:51)
    at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
    at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
    at java.lang.ClassLoader.<init>(ClassLoader.java:316)
    at sun.reflect.DelegatingClassLoader.<init>(ClassDefiner.java:72)
    at sun.reflect.ClassDefiner$1.run(ClassDefiner.java:60)
    at sun.reflect.ClassDefiner$1.run(ClassDefiner.java:58)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:57)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395)
    at sun.reflect.MethodAccessorGenerator.generateConstructor(MethodAccessorGenerator.java:94)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:48)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at Main$2.run(Main.java:65)
    at Main$2.run(Main.java:1)
    at java.security.AccessController.doPrivileged(Native Method)
    at Main.main(Main.java:58)

Почему я получаю другое поведение до и после использования этого кастома SecurityManager? Я не понимаю, почему программа будет давать разные результаты в этих случаях, так как в обоих случаях по умолчанию SecurityManager это тот, кто на самом деле делает все проверки безопасности.

Спасибо!

Answer 1

Код в вашем SecurityManager не кажется доверенным. Поэтому, когда он появляется во время проверки стека, проверка безопасности не пройдёт.

Почему не код main а также run вызвать ту же проблему? Мы можем видеть из стека трассировки тех элементов стека, которые участвуют в проверке безопасности.

at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
at java.security.AccessController.checkPermission(AccessController.java:559)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at Main$1.checkPermission(Main.java:51)
at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
at java.lang.ClassLoader.<init>(ClassLoader.java:316)
at sun.reflect.DelegatingClassLoader.<init>(ClassDefiner.java:72)
at sun.reflect.ClassDefiner$1.run(ClassDefiner.java:60)
at sun.reflect.ClassDefiner$1.run(ClassDefiner.java:58)
at java.security.AccessController.doPrivileged(Native Method)
at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:57)

Единственный несистемный кадр Main$1.checkPermission(Main.java:51), Удалите его, и проблема исчезнет.