2015-07-16 5 views
2

Я хочу, чтобы установить пользовательские Policy, определив свой собственный класс, который расширяет класс политики следующим образом:Policy.setPolicy(), кажется, не работать должным образом

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?
  • это выше проблемы с какой-то ошибкой или был класс политики намеренно дизайн, чтобы вести себя таким образом (если так - почему?)?

ответ

1

Есть «интересные» проблемы, связанные с механизмом безопасности на основе стека, когда части реализации могут не доверять. Это намного проще, когда он реализован с помощью классов начальной загрузки, поскольку проверка исключена для загрузчика классов null.

Когда вы ввели setPolicy в ProtectionDomain из Policy, ему были предоставлены все разрешения. Таким образом, весь ваш код имеет привилегию - не то, что вы хотели.

Для последующих setPolicy вызовов предыдущие Policy предоставляет разрешения PolicyProtectionDomain. В вашем случае это приведет к тому, что весь ваш код будет иметь ваши пустые разрешения PermissionCollection. (Вероятно, вы должны называть setReadOnly об этом - противном API. Также это абстрактный класс, поэтому его не следует компилировать.)

Итак, вы, вероятно, захотите использовать отдельный загрузчик классов для загрузки ненадежного кода и вашего механизма безопасности.

Только вы, вероятно, ушли и сломали много вещей, считая, что ничто не имеет никаких разрешений. Загрузочные классы получают пропуск из-за своего загрузчика классов null. Например, для загрузки классов, вероятно, требуются разрешения, поэтому вы не хотите отрицать все там.

Гораздо лучше использовать обычную конфигурацию файла политики для настройки политики.

+0

Спасибо за ответ!Вы правы - вышеуказанный код не будет компилироваться, вместо «PermissionCollection» я имел в виду «Разрешения». Я сделал вышеприведенный пример, чтобы проиллюстрировать проблему, поэтому отсутствие каких-либо разрешений на мой счет. Вы сказали, что классы загрузки получают пропуск из-за Bootstrap classloader - можете ли вы объяснить это немного дальше? Почему они получают пропуск, несмотря на то, что приложение не имеет никакого разрешения вообще? – pbgus

+0

классы @pgbus Boot имеют 'null'' ProtectionDomain'. Таким образом, нельзя назвать 'ProtectionDomain.implies'. –

Смежные вопросы