Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
java.lang.SecurityManager как Менеджер безопасности По умолчаниюJava SE архитектура безопасности JDK основана на политике, и учитывает мелкомодульное управление доступом. Когда код загружается, он присваивается "полномочия", основанные на политике безопасности в настоящий момент в действительности. Каждое разрешение определяет разрешенный доступ к определенному ресурсу, такой как "считано" и доступ "записи" к указанному файлу или каталогу, или доступ "подключения" к данному узлу и порту. Политика, определяя, какие полномочия доступны для кода от различных подписывающих лиц/расположений, может быть инициализирована от внешнего конфигурируемого файла политики. Если разрешение явно не предоставляют кодировать, оно не может получить доступ к ресурсу, который охраняет то разрешение. Это новое понятие разрешения и политики позволяет JDK предложить мелкий модуль, высоконастраиваемое, гибкое, и расширяемое управление доступом. Такое управление доступом может теперь не только быть определено для апплетов, но также и для всего кода Java, включая приложения, бобы, и сервлеты.
Для получения дополнительной информации по архитектуре безопасности Java, пожалуйста, см. безопасность documentaton.
SecurityManager класс содержит много методов с именами, которые начинаются со слова check. Примеры checkRead и checkConnect. Различные методы в библиотеках Java вызывают a check метод прежде, чем выполнить каждую потенциально секретную операцию безопасности. Менеджеру безопасности, таким образом, дают возможность предотвратить завершение работы, выдавая исключение. Подпрограмма менеджера безопасности просто возвращается, если работа разрешается, но бросает SecurityException, если работа не разрешается. Единственное исключение к этому соглашению checkTopLevelWindow, который возвращает булево значение.
Другой основной тип методов, содержавшихся в SecurityManager класс - связанные с существованием загрузчика класса и глубиной:
java.lang.SecurityManager был абстрактный класс. Реализации по умолчанию менеджера безопасности check методы выдавали исключения. Загрузчик класса и связанные с глубиной классы были соответственно реализованы, часто в собственном коде. Любое приложение (такое как браузер), который хотел установить менеджера безопасности, должно было записать их собственные, обеспечивающие соответствующие конкретные реализации методов, которые выдавали исключения по умолчанию - прежде всего check методы.
Менеджеры безопасности, основанные на JDK 1.1 модели менеджера безопасности апплета обычно базируемые решения управления доступом о двух вещах:
Эти типы решений были сделаны, вызывая SecurityManager методы, связанные с существованием загрузчика класса и глубиной. Например, у типичного менеджера безопасности с 1.1 стилями мог бы быть a checkExit метод как следующее:
public void checkExit(int status) {
if (inClassLoader()) {
throw new SecurityException(..);
}
}
Такой checkExit метод не позволил бы Runtime.exit быть вызванным, когда любой класс, определенный с помощью загрузчика класса (апплет), был на стеке. Это - пример первого случая, проверяя, является ли класс с загрузчиком класса на стеке. Пример второго случая (глубина загрузчика класса) был бы чем-то как:
public void checkCreateClassLoader() {
if (classLoaderDepth() == 2) {
throw new SecurityException();
}
}
Этот метод говорит, что глубина загрузчика класса не может быть 2. Таким образом, метод, который названный методом, который вызывал checkCreateClassLoader не должен быть в классе, определенном с помощью загрузчика класса. Например, конструктор для java.lang.ClassLoader вызовы checkCreateClassLoader, что означает метод, который вызывает конструктора для java.lang.ClassLoader не должен иметь загрузчика класса. Это означает, что апплеты не могут непосредственно создать загрузчики класса.
Отметьте, что есть большая разница между этими двумя методами, даже при том, что обе попытки препятствовать тому, чтобы апплеты выполнили действия. В первом случае, checkExit выдаст исключение, если апплет будет где-нибудь на стеке. Это означает, что даже встроенный код JDK не может выйти из VM, если это вызвали от апплета. Во втором случае коду JDK позволяют создать загрузчик класса, даже если это вызвал апплет. Это - то, потому что глубина класса с загрузчиком класса используется, а не факт, что есть тот.
java.lang.SecurityManager если бы много изменений сделали к этому, чтобы позволить этому использоваться в качестве менеджера безопасности по умолчанию для приложений. В особенности: abstract класс, и может таким образом быть установлен как есть.check методы вызывают новое checkPermission метод, который значением по умолчанию вызывает метод того же самого имени (checkPermission) в новом AccessController класс. Те методы, которые не вызывают checkPermission имейте разумные значения по умолчанию.java.security.AllPermission.java.lang.SecurityManager как Менеджер безопасности По умолчаниюС тех пор java.lang.SecurityManager больше не абстрактно, можно установить и использовать это в качестве менеджера безопасности по умолчанию. Можно сделать это, устанавливая системное свойство, запуская VM:
java -Djava.security.manager YourApp
Альтернативно, Ваше приложение может установить это непосредственно через следующую строку кода:
System.setSecurityManager(new SecurityManager());
Можно настроить поведение менеджера безопасности по умолчанию, изменяя файлы политики. См. руководство по обеспечению безопасности на файлах политики для получения дополнительной информации. В JDK, SecurityManager методы, связанные, чтобы классифицировать загрузчики и глубину загрузчика класса, не вызывает ни один из check методы, и они осуждаются. Они не должны использоваться никакими новыми менеджерами безопасности, и рекомендуется, чтобы их использование было устранено из существующих менеджеров безопасности также. Однако, они оставляются внутри для обратной совместимости, и они были изменены в попытке позволить старым менеджерам безопасности с 1.1 стилями все еще работать под JDK без модификации.
Эти методы:
Загрузчик/глубина класса связанные методы был все изменен тремя способами:
ClassLoader.getSystemClassLoader) или один из его предков. Так как классы, загруженные системным загрузчиком класса, включают классы приложений (загруженный прочь CLASSPATH), классы расширения, и встроенные классы JDK, эта модификация позволяет этим методам проигнорировать такой код.
Отметьте что, если Вы запускаете приложение, которое устанавливает пользовательского менеджера безопасности, и что менеджер безопасности загружается прочь CLASSPATH в JDK у этого будет системный загрузчик класса связанным с этим. (У классов приложений не было загрузчика класса в JDK 1.1.), Если Вы должны были вызвать метод как classLoaderDepth изнутри пользовательского менеджера безопасности, и того метода не были изменены, чтобы проигнорировать классы, загруженные системным загрузчиком класса, это будет всегда возвращаться 0, который не был бы очень полезен. Точно так же, если методы загрузчика класса не были изменены, чтобы пропустить системные классы, и пользовательский менеджер безопасности был загружен прочь CLASSPATH, тогда это могло бы также открыть дыры в системе безопасности в случаях, где менеджер безопасности является принятием решений, основанным на, например, отвергая работу если "classLoaderDepth () == 2". (Это должно действительно быть "classLoaderDepth () <= 2".)
AllPermission как будто нет никакого загрузчика класса на стеке.Как пример использования первых двух модификаций, отметьте, что есть теперь места в JDK, которые открывают файлы, и т.д., после того, как менеджер безопасности был установлен. У некоторых менеджеров безопасности с 1.1 стилями есть a checkRead метод, который похож на следующее:
public void checkRead(String file) {
if (inClassLoader()) {
throw new SecurityException(..);
}
}
Без модификаций кода JDK такая проверка, осуществленная в JDK, заставила бы исключение безопасности быть брошенным, когда сам JDK пытается считать файл и есть класс с несистемным загрузчиком класса на стеке. С новой моделью обеспечения безопасности у всего такого кода JDK, который пытается выполнить работу, которую ее вызывающей стороне нельзя было бы позволить сделать, есть a doPrivileged блок вокруг этого. С тех пор inClassLoader только исследует стек до и включая фрейм, содержащий "привилегированный" код, и код наверху стека является кодом JDK, который загружается системным загрузчиком класса или одним из его предков, inClassLoader метод возвратится false, разрешение чтения произойти.
Как отмечено ранее, менеджеры безопасности, основанные на 1.1 менеджерах безопасности апплета, базируемых некоторые из их решений управления доступом о глубине загрузчика класса. Как пример, checkCreateClassLoader методика, ранее представленная, повторяется здесь:
public void checkCreateClassLoader() {
if (classLoaderDepth() == 2) {
throw new SecurityException();
}
}
В JDK мы попытались поддержать глубину стека как использующийся в менеджерах безопасности с 1.1 стилями. Например, конструктор для java.security. У SecureClassLoader есть явный звонок SecurityManager.checkCreateClassLoader даже при том, что конструктор для его класса высшего качества (ClassLoder) также делает. Если проверка не была помещена в конструктора для SecureClassLoader, тогда менеджер безопасности с 1.1 стилями позволил бы недоверяемому коду расширяться SecureClassLoader и создайте загрузчики класса, поскольку глубина загрузчика класса всегда была бы больше чем 2. Прежде всего мы настоятельно рекомендуем анализ всех Ваших пользовательских методов менеджера безопасности прежде, чем выполнить Вашего менеджера безопасности под JDK. Отказ сделать так мог привести к дыре в системе безопасности или предотвратить правильное функционирование JDK. Это происходит из-за хрупкости менеджеров безопасности с 1.1 стилями.
Где только возможно следует только использовать реализацию по умолчанию 1.2 SecurityManager. Это помогает дать пользователям и администраторам непротиворечивое поведение. Если это не возможно, то следует, по крайней мере, попытаться вызвать super.checkXXX в Вашем checkXXX метод прежде, чем выдать исключение безопасности. Выполнение так позволит алгоритму контроллера доступа использоваться, и позволит JDK непосредственно функционировать правильно.
В JDK, любой существующий код, который имел обыкновение вызывать любой из SecurityManager check методы продолжают делать так. Для нового кода, который требует проверки защиты, вызовы выполняются к SecurityManager.checkPermission вместо того, чтобы добавить новое SecurityManager check метод. Например, новое java.lang.System.setProperty вызовы метода checkPermission с a java.util.PropertyPermission разрешение.
Расширяя класс SecurityManager и переопределяя существующие методы, некоторая забота должна быть проявлена. Например, если Вы переопределяете checkRead(String file) метод, таким образом, это всегда выдает исключение безопасности, тогда сам JDK, может быть не в состоянии работать должным образом. Таким образом, если некоторый код JDK должен открыть файл (чтобы считать файл свойств, загрузите файл JAR, и т.д.), тогда выдача исключения безопасности для каждой попытки чтения вызвала бы такой, открывается ко всегда сбою.
Вообще, следует только переопределить методы по умолчанию, если Вы намереваетесь ослабить безопасность, не сделать ее более сильной. Если Вы хотите сжать безопасность, следует изменить файлы политики по умолчанию и/или установить пользовательское java.security.Policy объект. См. руководство по обеспечению безопасности на файлах политики для получения дополнительной информации.
Вообще, переопределяя методы менеджера безопасности следует заказать телефонный разговор с super.checkXXX метод в точке, где Ваш переопределенный checkXXX метод выдал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkRead(String file) {
if (someCustomSecurityCheckFails()) {
super.checkRead(file);
}
}
}
Если Ваша пользовательская проверка защиты перестала работать, то super.checkRead вызывается. Реализация по умолчанию checkRead вызывает checkPermission, который по умолчанию консультируется AccessController. Вызывая AccessController, системный код, который сделал AccessController.doPrivileged прежде, чем попытаться считать файл преуспеет в том, чтобы читать тот файл. Весь другой код будет подвергнут текущей политике в действительности, и исключение управления доступом будет выдано, если доступ к тому файлу не был предоставлен. Отметьте, есть некоторые checkXXX методы, в которых недопустимо вызвать super.checkXXX методы, переопределяя их. Это - то, потому что реализация по умолчанию этих методов, возможно, не столь же строга как политика, которую Вы реализуете в переопределенном методе. Например, значение по умолчанию checkAccess(ThreadGroup g) метод только защищает системную группу потока. Если Вы намереваетесь защитить потоки в отличных группах потока друг от друга (например группы потока апплета), то Вы не хотели бы вызывать super.checkAccess в точке Вы обычно выдавали бы исключение безопасности, поскольку это победит цель Вашей специализированной проверки. Вместо этого Вы могли заказать телефонный разговор с super.checkAccess как первый оператор в Вашем переопределенном методе.
Например:
public class AppletSecurityManager extends SecurityManager {
public void checkAccess(ThreadGroup g) {
// a call to super will throw an exception if someone
// is trying to modify the system thread group
super.checkAccess(g);
...
// now perform checks based on which applet thread group
// the current caller is in to see if they can modify thread group g.
...
}
Мы описываем, как переопределить каждый метод в следующем разделе.
java.lang.SecurityManager методы в JDK и обеспечивают предложения относительно любых переопределений, которые можно хотеть сделать. Пожалуйста, см. документацию Java для SecurityManager класс для получения дополнительной информации об этих методах. Это поле было осуждено, и любое использование этого поля в пределах самого JDK было удалено. Вместо того, чтобы использовать inCheck, следует использовать checkPermission наряду с doPrivileged.
Этот метод был также осужден.
Конструктор был изменен, чтобы позволить многократному SecurityManagers создаваться, предполагая, что вызывающая сторона имеет RuntimePermission("createSecurityManager") разрешение.
Никакие изменения. Этот вызов может использоваться, чтобы эмулировать 1.1 поведения методов, которые были изменены в JDK ( currentClassLoader, currentLoadedClass, classLoaderDepth, inClassLoader).
Типичное использование этого метода в JDK, который должны были видеть менеджеры безопасности с 1.1 стилями, был ли там загрузчик класса на стеке, и в противном случае обрабатывают код как "доверяющийся" и позволяет этому делать что-нибудь. Этот метод был изменен в JDK, чтобы позволить код JDK, которому доверяют (фактически любой предоставленный код java.security.AllPermission) это вызывает doPrivileged быть обработанным как доверяющийся менеджерами безопасности с 1.1 стилями. Это было также изменено, чтобы пропустить системные загрузчики класса. Системный загрузчик класса определяется как являющийся загрузчиком класса, который равен системному загрузчику класса (как возвращено ClassLoader.getSystemClassLoader) или один из его предков.
Этот метод возвратится null в следующих трех случаях:
java.security.AllPermission не приводит к SecurityException.Этот метод был осужден. Использовать checkPermission вместо этого.
Этот метод был изменен тем же самым способом как currentClassLoader, и возвратится null если текущий контекст защиты предоставили AllPermission или все методы на стеке (до первой привилегированной вызывающей стороны, если кто-либо) от классов, определенных, используя системный загрузчик класса или одного из его предков.
Этот метод был осужден. Использовать checkPermission вместо этого.
Никакие изменения в поведении. Этот метод был осужден. Использовать checkPermission вместо этого.
Этот метод был изменен тем же самым способом как currentClassLoader, и возвратится -1 если текущий контекст защиты предоставили AllPermission или все методы на стеке (до первой привилегированной вызывающей стороны, если кто-либо) от классов, определенных, используя системный загрузчик класса или одного из его предков.
Этот метод был осужден. Использовать checkPermission вместо этого.
Никакие изменения в поведении. Этот метод был осужден. Использовать checkPermission вместо этого.
Этот метод возвращает true если currentClassLoader возвращает ненулевой загрузчик класса, таким образом, он следует за той же самой семантикой что currentClassLoader делает.
Этот метод был осужден. Использовать checkPermission вместо этого.
Этот метод возвращает a java.security.AccessControlContext объект, который создается со звонком java.security.AccessController.getContext. В JDK1.1 это возвратилось null по умолчанию.
Этот метод нов в JDK. Это вызывает java.security.AccessController.checkPermission с данным разрешением. Внутренне, JDK всегда вызывает SecurityManager.checkPermission вместо того, чтобы вызвать AccessController непосредственно. Это позволяет людям переопределять этот метод, чтобы обеспечить дополнительную функциональность, такую как диалоговые окна GUI и/или контроль.
Этот метод нов в JDK. Если context экземпляр AccessControlContext тогда AccessControlContext.checkPermission метод будет вызван на данный контекст с указанным разрешением.
Если context не экземпляр AccessControlContext тогда a SecurityException бросается.
Этот метод был изменен, чтобы вызвать checkPermission с RuntimePermission("createClassLoader") разрешение.
Если этот метод переопределяется, то звонок super.checkCreateClassLoader должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkCreateClassLoader() {
if (someCustomSecurityCheckFails()) {
super.checkCreateClassLoader();
}
}
}
Если параметром потока является системный поток (принадлежит группе потока с a null родитель) тогда это вызовы метода checkPermission с RuntimePermission("modifyThread") разрешение.
Приложения, которые хотят более строгую политику, должны переопределить этот метод.
Если этот метод переопределяется, то super.checkAccess должен быть вызван первым оператором в переопределенном методе, или эквивалентная проверка защиты должна быть помещена в переопределенный метод.
Если этот метод переопределяется, метод, который переопределяет его, должен дополнительно проверить, чтобы видеть, имеет ли вызывающий поток RuntimePermission("modifyThread") разрешение, и если так, возвращается тихо. Это должно гарантировать, что код, предоставленный, что разрешению (такому как JDK непосредственно) позволяют управлять любым потоком.
Например:
public class MySecurityManager extends SecurityManager {
public void checkAccess(Thread t) {
// a call to super will throw an exception if someone
// is trying to modify a system thread
super.checkAccess(t);
...
if (someCustomSecurityCheckForOtherThreadsFails()) {
// if the check fails, instead of throwing an exception,
// call checkPermission, which will throw an exception
// if need be
checkPermission(new RuntimePermission("modifyThread"));
}
...
}
}
Если групповым параметром потока является системная группа потока (имеет a null родитель) тогда это вызовы метода checkPermission с RuntimePermission("modifyThreadGroup") разрешение.
Приложения, которые хотят более строгую политику, должны переопределить этот метод.
Если этот метод переопределяется, то super.checkAccess должен быть вызван первым оператором в переопределенном методе, или эквивалентная проверка защиты должна быть помещена в переопределенный метод.
Если этот метод переопределяется, метод, который переопределяет его, должен дополнительно проверить, чтобы видеть, имеет ли вызывающая сторона RuntimePermission("modifyThreadGroup") разрешение, и если так, возвращается тихо. Это должно гарантировать, что код, предоставленный, что разрешению (такому как JDK непосредственно) позволяют управлять любой группой потока.
Например:
public class MySecurityManager extends SecurityManager {
public void checkAccess(ThreadGroup g) {
// a call to super will throw an exception if someone
// is trying to modify the system thread group
super.checkAccess(g);
...
if (someCustomSecurityCheckForOtherThreadGroupsFails()) {
// if the check fails, instead of throwing an exception,
// call checkPermission, which will throw an exception
// if need be
checkPermission(new RuntimePermission("modifyThreadGroup"));
}
...
}
}
Этот метод был изменен, чтобы вызвать checkPermission с RuntimePermission("exitVM") разрешение.
Если этот метод переопределяется, то звонок super.checkExit должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkExit(int status) {
if (someCustomSecurityCheckFails()) {
super.checkExit(status);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с a FilePermission. Если cmd абсолютный путь (см. java.io.File.isAbsolute) тогда это передают как есть как цель для FilePermission. Если cmd не является абсолютным, тогда специальная цель" <<ВСЕ ФАЙЛЫ>>" используются. Эта цель используется, потому что трудно определить фактический путь команды, которая будет выполняться на отдельной платформе из-за вещей, таких как переменные окружения и т.д.
Если этот метод переопределяется, то звонок super.checkExec должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkExec(String cmd) {
if (someCustomSecurityCheckFails()) {
super.checkExec(cmd);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с RuntimePermission("loadLibrary."+lib) разрешение.
Если этот метод переопределяется, то звонок super.checkLink должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkLink(String lib) {
if (someCustomSecurityCheckFails()) {
super.checkLink(lib);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с RuntimePermission("readFileDescriptor") разрешение.
Если этот метод переопределяется, то звонок super.checkRead должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkRead(FileDescriptor fd) {
if (someCustomSecurityCheckFails()) {
super.checkRead(fd);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с FilePermission(file,"read") разрешение.
Если этот метод переопределяется, то звонок super.checkRead должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkRead(String file) {
if (someCustomSecurityCheckFails()) {
super.checkRead(file);
}
}
}
Этот метод был изменен. Если context экземпляр AccessControlContext тогда AccessControlContext.checkPermission метод будет вызван на данный контекст с FilePermission(file,"read") разрешение.
Если context не экземпляр AccessControlContext тогда a SecurityException бросается.
Если этот метод переопределяется, то звонок super.checkRead должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkRead(String file, Object context) {
if (someCustomSecurityCheckFails()) {
super.checkRead(file, context);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с RuntimePermission("writeFileDescriptor") разрешение.
Если этот метод переопределяется, то звонок super.checkWrite должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkWrite(FileDescriptor fd) {
if (someCustomSecurityCheckFails()) {
super.checkWrite(fd);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с FilePermission(file,"write") разрешение.
Если этот метод переопределяется, то звонок super.checkWrite должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkWrite(String file) {
if (someCustomSecurityCheckFails()) {
super.checkWrite(file);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с FilePermission(file,"delete") разрешение.
Если этот метод переопределяется, то звонок super.checkDelete должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkDelete(String file) {
if (someCustomSecurityCheckFails()) {
super.checkDelete(file);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с SocketPermission(host+":"+port,"connect") разрешение, если порт не равен-1. Если порт равен-1, то он вызывает checkPermission с SocketPermission(host,"resolve") разрешение.
Это поведение является непротиворечивым с JDK 1.1, где порт, равный-1, указывает, что поиск IP-адреса выполняется.
Если этот метод переопределяется, то звонок super.checkConnect должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkConnect(String host, int port) {
if (someCustomSecurityCheckFails()) {
super.checkConnect(host, port);
}
}
}
Этот метод был изменен. Если context экземпляр AccessControlContext тогда AccessControlContext.checkPermission метод будет вызван на данный контекст с SocketPermission(host+":"+port,"connect") разрешение, если порт не равен-1. Если порт равен-1, то он вызывает checkPermission с SocketPermission(host,"resolve") разрешение.
Если context не экземпляр AccessControlContext тогда a SecurityException бросается.
Если этот метод переопределяется, то звонок super.checkConnect должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkConnect(String host, int port, Object context) {
if (someCustomSecurityCheckFails()) {
super.checkConnect(host, port, context);
}
}
}
Этот метод был изменен. Если порт не 0, он вызывает checkPermission с SocketPermission("localhost:"+port,"listen"). Если порт является нулем, он вызывает checkPermission с SocketPermission("localhost:1024-","listen").
Если этот метод переопределяется, то звонок super.checkListen должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkListen(int port) {
if (someCustomSecurityCheckFails()) {
super.checkListen(port);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с SocketPermission(host+":"+port,"accept") разрешение.
Если этот метод переопределяется, то звонок super.checkAccept должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkAccept(String host, int port) {
if (someCustomSecurityCheckFails()) {
super.checkAccept(host, port);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с SocketPermission(maddr.getHostAddress(),"accept,connect") разрешение.
Если этот метод переопределяется, то звонок super.checkMulticast должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkMultiCast(InetAddress maddr) {
if (someCustomSecurityCheckFails()) {
super.checkMultiCast(maddr);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с SocketPermission(maddr.getHostAddress(),"accept,connect") разрешение.
Если этот метод переопределяется, то звонок super.checkMulticast должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkMultiCast(InetAddress maddr, byte ttl) {
if (someCustomSecurityCheckFails()) {
super.checkMultiCast(maddr, ttl);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с PropertyPermission("*", "read,write") разрешение.
Если этот метод переопределяется, то звонок super.checkPropertiesAccess должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkPropertiesAccess() {
if (someCustomSecurityCheckFails()) {
super.checkPropertiesAccess();
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с PropertyPermission(key, "read") разрешение.
Если этот метод переопределяется, то звонок super.checkPropertyAccess должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkPropertyAccess(String key) {
if (someCustomSecurityCheckFails()) {
super.checkPropertiesAccess(key);
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с AWTPermission("showWindowWithoutWarningBanner") разрешение, и возвращает true, если SecurityException не бросается, иначе это возвращает false.
Если этот метод переопределяется, то звонок super.checkTopLevelWindow должен быть сделан в точке, из которой переопределенный метод обычно возвращал бы false, и значение super.checkTopLevelWindow должен быть возвращен. Например:
public class MySecurityManager extends SecurityManager {
public void checkTopLevelWindow(Object window) {
if (someCustomSecurityCheckFails()) {
return super.checkTopLevelWindow(window);
} else {
return true;
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с RuntimePermission("queuePrintJob") разрешение.
Если этот метод переопределяется, то звонок super.checkPrintJobAccess должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkPrintJobAccess() {
if (someCustomSecurityCheckFails()) {
super.checkPrintJobAccess();
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с AWTPermission("accessClipboard") разрешение.
Если этот метод переопределяется, то звонок super.checkSystemClipboardAccess должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkSystemClipboardAccess() {
if (someCustomSecurityCheckFails()) {
super.checkSystemClipboardAccess();
}
}
}
Этот метод был изменен, чтобы вызвать checkPermission с AWTPermission("accessEventQueue") разрешение.
Если этот метод переопределяется, то звонок super.checkAwtEventQueueAccess должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkAwtEventQueueAccess() {
if (someCustomSecurityCheckFails()) {
super.checkAwtEventQueueAccess();
}
}
}
Этот метод был изменен. Это сначала получает список ограниченных пакетов, получая список разделенных запятой значений из звонка java.security.Security.getProperty("package.access"), и проверки, чтобы видеть, если pkg запускается с или равняется любому из ограниченных пакетов. Если это делает, то checkPermission вызывается с RuntimePermission("accessClassInPackage."+pkg) разрешение.
Если этот метод переопределяется, то super.checkPackageAccess должен быть вызван как первая строка в переопределенном методе. Например:
public class MySecurityManager extends SecurityManager {
public void checkPackageAccess(String pkg) {
super.checkPackageAccess(pkg);
...
someCustomSecurityCheck();
...
}
}
Этот метод был изменен. Это сначала получает список ограниченных пакетов, получая список разделенных запятой значений из звонка java.security.Security.getProperty("package.definition"), и проверки, чтобы видеть, если pkg запускается с или равняется любому из ограниченных пакетов. Если это делает, то checkPermission вызывается с RuntimePermission("defineClassInPackage."+pkg) разрешение.
Если этот метод переопределяется, то super.checkPackageDefinition должен быть вызван как первая строка в переопределенном методе. Например:
public class MySecurityManager extends SecurityManager {
public void checkPackageDefinition(String pkg) {
super.checkPackageDefinition(pkg);
...
someCustomSecurityCheck();
...
}
}
Этот метод был изменен, чтобы вызвать checkPermission с RuntimePermission("setFactory") разрешение.
Если этот метод переопределяется, то звонок super.checkSetFactory должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkSetFactory() {
if (someCustomSecurityCheckFails()) {
super.checkSetFactory();
}
}
}
Этот метод был изменен. Политика по умолчанию состоит в том, чтобы предоставить доступ к элементам PUBLIC, так же как доступ к классам, у которых есть тот же самый загрузчик класса как вызывающая сторона. Во всем другом вызове случаев checkPermission с RuntimePermission("accessDeclaredMembers") разрешение.
Если этот метод переопределяется, то звонок super.checkMemberAccess не может быть сделан, как реализация по умолчанию checkMemberAccess полагается на код, проверяемый, будучи в глубине стека 4. Например:
someCaller[3]
java.lang.Class.someReflectionAPI [2]
java.lang.Class.checkMemberAccess [1]
SecurityManager.checkMemberAccess [0]
Чтобы эмулировать это поведение, Вы должны были бы вызвать getClassContext, и исследуйте загрузчик класса класса по индексу 3, так же, как значение по умолчанию checkMemberAccess метод делает:
if (which != Member.PUBLIC) {
Class stack[] = getClassContext();
/*
* stack depth of 4 should be the caller of one of the
* methods in java.lang.Class that invoke checkMember
* access. The stack should look like:
*
* someCaller [3]
* java.lang.Class.someReflectionAPI [2]
* java.lang.Class.checkMemberAccess [1]
* MySecurityManager.checkMemberAccess [0]
*
*/
if ((stack.length<4) ||
(stack[3].getClassLoader() != clazz.getClassLoader())) {
if (checkMemberAccessPermission == null)
checkMemberAccessPermission =
new RuntimePermission("accessDeclaredMembers");
checkPermission(checkMemberAccessPermission);
}
}
Это - единственный метод менеджера безопасности в JDK, который все еще основан на глубине вызывающей стороны. Это должно позволить вызывающей стороне размышлять над классами от того же самого загрузчика класса, из которого она прибыла.
Этот метод был изменен, чтобы создать a SecurityPermission объект для данного разрешения предназначается для имени и вызовов checkPermission с этим.
Если этот метод переопределяется, то звонок super.checkSecurityAccess должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager {
public void checkSecurityAccess(String target) {
if (someCustomSecurityCheckFails()) {
super.checkSecurityAccess(target);
}
}
}
Этот метод не был изменен.
