Java SecurityManager несколько потоков - PullRequest
2 голосов
/ 10 мая 2011

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

Ответы [ 3 ]

3 голосов
/ 10 мая 2011

Вы используете один менеджер безопасности для всего вашего приложения.инфраструктура безопасности Java была разработана для обработки этого сценария.способ заставить вещи работать, используя функцию кодовых баз файла политики, которая позволяет назначать разные разрешения для разных кодовых баз.Вы можете назначить своей "основной" кодовой базе "все права доступа", и она будет работать как обычно.Вы можете назначить любой импортированный код для ограниченной кодовой базы.

все это тщательно документировано здесь , вероятно, наиболее важной частью этой проблемы является информация файла политики .

3 голосов
/ 10 мая 2011

Ваш SecurityManager может проверить, какой поток запущен. Это будет делать простой локальный поток, однако вам может потребоваться InheritableThreadLocal, чтобы любые созданные дополнительные потоки «наследовали» уровень безопасности потоков.

0 голосов
/ 10 мая 2011

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

...