Java: существует ли API для определения, какому классу требуется разрешение в пользовательском классе Security Manager?

#java #securitymanager

#java #securitymanager

Вопрос:

Я пытаюсь найти, какой класс динамически запрашивал разрешение в пользовательском Security manager. Я не смог найти ни одного API, который помог бы мне получить местоположение кодовой базы вызывающего класса. Ниже то, что я пытаюсь сделать,

У меня есть класс TestApp, который пытается выполнить запись в файл,

 package test.ProfilingSecurityManager;
import java.io.PrintWriter;
public class TestApp {
public static void main(String [] args) throws Exception {
    System.setSecurityManager(new NewProfilingSecurityManger());
    PrintWriter writer = new PrintWriter("profile.txt");
    writer.println("Test line");
    writer.close();
}
}
 

Переопределенный метод в пользовательском Security Manager приведен ниже,

 public void checkPermission(final Permission permission) {
  try {
  // see what the parent security manager code says
  super.checkPermission(permission);
  } 
  catch (Exception e) {
   // find the code base which requested this permission
   // I can get the call stack here
   Class [] sourceClasses = getClassContext();
   Class invokingClass = sourceClasses[sourceClasses.length - 1];
   // I can also get the accesscontrol context here  
   // using -AccessController.getContext()
   // How do i find the codebase location of the class 
   // which needed this permission here
 }
}
 

Мне нужно найти расположение кодовой базы TestApp, когда исключение генерируется внутри метода checkPermission .
Может ли кто-нибудь помочь мне в том, как это сделать?

Спасибо

Комментарии:

1. вы проверили nio pakeage?

2. Нет. Поможет ли это в том, чего я пытаюсь достичь?

3. Нет, это не так. NIO не имеет ничего общего с Security manager. комментарий @KickButtowski не имеет смысла.

Ответ №1:

Если вы вызовете invokingClass.getProtectionDomain().getCodeSource(), это сообщит вам, откуда был загружен этот класс.

Однако это только сообщит вам, какой класс находился в нижней части стека вызовов, когда проверка доступа не удалась. В приведенном вами примере это будет TestApp, но если вы пытаетесь устранить проблемы с разрешениями безопасности, лучшим подходом является запуск Java с java.security.debug системным свойством, установленным на access,failure . Когда проверка разрешений завершается неудачей, это сообщит вам, у какого класса не было разрешения, откуда он был загружен и какие разрешения у него есть.