Spec-Zone .ru
спецификации, руководства, описания, API
|
java.lang.SecurityManager
как Менеджер безопасности Значения по умолчаниюJava SE архитектура безопасности JDK основана на политике, и учитывает мелкомодульное управление доступом. Когда код загружается, он присваивается "полномочия", основанные на политике безопасности в настоящий момент в действительности. Каждое разрешение определяет разрешенный доступ к определенному ресурсу, такой как "считано" и доступ "записи" к указанному файлу или каталогу, или "соедините" доступ к данному узлу и порту. Политика, определяя, какие полномочия доступны для кода от различных подписывающих лиц/расположений, может быть инициализирована от внешнего конфигурируемого файла политики. Если разрешение явно не предоставляют кодировать, оно не может получить доступ к ресурсу, который охраняет то разрешение. Это новое понятие разрешения и политики позволяет JDK предложить мелкий модуль, высоконастраиваемое, гибкое, и расширяемое управление доступом. Такое управление доступом может теперь не только быть определено для апплетов, но также и для всего кода Java, включая приложения, бобы, и сервлеты.
Для получения дополнительной информации по архитектуре безопасности Java, пожалуйста, см. безопасность documentaton.
SecurityManager
class содержит много методов с именами, которые начинаются со слова check
. Примеры checkRead
и checkConnect
. Различные методы в библиотеках Java вызывают a check
метод прежде, чем выполнить каждую потенциально секретную операцию безопасности. Менеджеру безопасности, таким образом, дают возможность предотвратить завершение работы, выдавая исключение. Подпрограмма менеджера безопасности просто возвращается, если работа разрешается, но бросает SecurityException, если работа не разрешается. Единственное исключение к этому соглашению checkTopLevelWindow
, который возвращает булево значение.
Другой основной тип методов, содержавшихся в SecurityManager
class - связанные с существованием загрузчика class и глубиной:
java.lang.SecurityManager
был абстрактный class. Реализации по умолчанию менеджера безопасности check
методы выдавали исключения. Загрузчик class и связанные с глубиной классы были соответственно реализованы, часто в собственном коде. Любое приложение (такое как браузер), который хотел установить менеджера безопасности, должно было записать их собственные, обеспечивающие соответствующие конкретные реализации методов, которые выдавали исключения по умолчанию - прежде всего check
методы.
Менеджеры безопасности, основанные на JDK 1.1 модели менеджера безопасности апплета обычно базируемые решения управления доступом о двух вещах:
Эти типы решений были сделаны, вызывая SecurityManager
методы, связанные с существованием загрузчика class и глубиной. Например, у типичного менеджера безопасности с 1.1 стилями мог бы быть a checkExit
метод как следующее:
public void checkExit(int status) { if (inClassLoader()) { throw new SecurityException(..); } }
Такой checkExit
метод не позволил бы Runtime.exit
быть вызванным, когда любой class, определенный с помощью загрузчика class (апплет), был на стеке. Это - пример первого случая, проверяя, является ли class с загрузчиком class на стеке. Пример второго случая (глубина загрузчика class) был бы чем-то как:
public void checkCreateClassLoader() { if (classLoaderDepth() == 2) { throw new SecurityException(); } }
Этот метод говорит, что глубина загрузчика class не может быть 2. Таким образом, метод, который названный методом, который вызывал checkCreateClassLoader
не должен быть в class, определенном с помощью загрузчика class. Например, конструктор для java.lang.ClassLoader
вызовы checkCreateClassLoader
, что означает метод, который вызывает конструктора для java.lang.ClassLoader
не должен иметь загрузчика class. Это означает, что апплеты не могут непосредственно создать загрузчики class.
Отметьте, что есть большая разница между этими двумя методами, даже при том, что обе попытки препятствовать тому, чтобы апплеты выполнили действия. В первом случае, checkExit
выдаст исключение, если апплет будет где-нибудь на стеке. Это означает, что даже встроенный код JDK не может выйти из VM, если это вызвали от апплета. Во втором случае коду JDK позволяют создать загрузчик class, даже если это вызвал апплет. Это - то, потому что глубина class с загрузчиком class используется, а не факт, что есть тот.
java.lang.SecurityManager
если бы много изменений сделали к этому, чтобы позволить этому использоваться в качестве менеджера безопасности значения по умолчанию для приложений. В особенности: abstract
class, и может таким образом быть установлен как есть.check
методы вызывают новое checkPermission
метод, который значением по умолчанию вызывает метод того же самого имени (checkPermission
) в новом AccessController
class. Те методы, которые не вызывают checkPermission
имейте разумные значения по умолчанию.java.security.AllPermission
.java.lang.SecurityManager
как Менеджер безопасности Значения по умолчаниюС тех пор java.lang.SecurityManager
больше не абстрактно, можно установить и использовать это в качестве менеджера безопасности значения по умолчанию. Можно сделать это, устанавливая системное свойство, запуская VM:
java -Djava.security.manager YourAppАльтернативно, Ваше приложение может установить это непосредственно через следующую строку кода:
System.setSecurityManager(new SecurityManager());Можно настроить поведение менеджера безопасности значения по умолчанию, изменяя файлы политики. См. руководство по обеспечению безопасности на файлах политики для получения дополнительной информации.
В JDK, SecurityManager
методы, связанные с загрузчиками class и глубиной загрузчика class, не вызывает ни один из check
методы, и они осуждаются. Они не должны использоваться никакими новыми менеджерами безопасности, и рекомендуется, чтобы их использование было устранено из существующих менеджеров безопасности также. Однако, они оставляются внутри для обратной совместимости, и они были изменены в попытке позволить старым менеджерам безопасности с 1.1 стилями все еще работать под JDK без модификации.
Эти методы:
Загрузчик/глубина class связанные методы был все изменен тремя способами:
ClassLoader.getSystemClassLoader
) или один из его предков. Начиная с классов, загруженных системой загрузчик class, включают классы приложений (загруженный прочь CLASSPATH
), классы расширения, и встроенные классы JDK, эта модификация позволяет этим методам проигнорировать такой код.
Отметьте что, если Вы запускаете приложение, которое устанавливает пользовательского менеджера безопасности, и что менеджер безопасности загружается прочь CLASSPATH
в JDK у этого будет система загрузчиком class связанный с этим. (У классов приложений не было загрузчика class в JDK 1.1.), Если Вы должны были вызвать метод как classLoaderDepth
изнутри пользовательского менеджера безопасности, и того метода не были изменены, чтобы проигнорировать классы, загруженные системой загрузчик class, это будет всегда возвращаться 0, который не был бы очень полезен. Точно так же, если методы загрузчика class не были изменены, чтобы пропустить системные классы, и пользовательский менеджер безопасности был загружен прочь CLASSPATH
, тогда это могло бы также открыть дыры в системе безопасности в случаях, где менеджер безопасности является принятием решений, основанным на, например, отвергая работу если "classLoaderDepth () == 2". (Это должно действительно быть "classLoaderDepth () <= 2".)
AllPermission
как будто нет никакого загрузчика class на стеке.Как пример использования первых двух модификаций, отметьте, что есть теперь места в JDK, которые открывают файлы, и т.д., после того, как менеджер безопасности был установлен. У некоторых менеджеров безопасности с 1.1 стилями есть a checkRead
метод, который похож на следующее:
public void checkRead(String file) { if (inClassLoader()) { throw new SecurityException(..); } }
Без модификаций кода JDK такая проверка, осуществленная в JDK, заставила бы исключение безопасности быть брошенным, когда сам JDK пытается считать файл и есть class с несистемным загрузчиком class на стеке. С новой моделью обеспечения безопасности у всего такого кода JDK, который пытается выполнить работу, которую ее вызывающей стороне нельзя было бы позволить сделать, есть a doPrivileged
блок вокруг этого. С тех пор inClassLoader
только исследует стек до и включая фрейм, содержащий "привилегированный" код, и код наверху стека является кодом JDK, который загружается системой загрузчик class или один из его предков, inClassLoader
метод возвратится false
, разрешение чтения произойти.
Как отмечено ранее, менеджеры безопасности, основанные на 1.1 менеджерах безопасности апплета, базируемых некоторые из их решений управления доступом о глубине загрузчика class. Как пример, checkCreateClassLoader
методика, ранее представленная, повторяется здесь:
public void checkCreateClassLoader() { if (classLoaderDepth() == 2) { throw new SecurityException(); } }В JDK мы попытались поддержать глубину стека как использующийся в менеджерах безопасности с 1.1 стилями. Например, конструктор для java.security. У SecureClassLoader есть явный звонок
SecurityManager.checkCreateClassLoader
даже при том, что конструктор для его class высшего качества (ClassLoder) также делает. Если проверка не была помещена в конструктора для SecureClassLoader
, тогда менеджер безопасности с 1.1 стилями позволил бы недоверяемому коду расширяться SecureClassLoader
и создайте загрузчики class, поскольку глубина загрузчика class всегда была бы больше чем 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 class и переопределяя существующие методы, некоторая забота должна быть проявлена. Например, если Вы переопределяете 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
class для получения дополнительной информации об этих методах. Это поле было осуждено, и любое использование этого поля в пределах самого JDK было удалено. Вместо того, чтобы использовать inCheck, следует использовать checkPermission
наряду с doPrivileged
.
Этот метод был также осужден.
Конструктор был изменен, чтобы позволить многократному SecurityManagers создаваться, предполагая, что вызывающая сторона имеет RuntimePermission("createSecurityManager")
разрешение.
Никакие изменения. Этот вызов может использоваться, чтобы эмулировать 1.1 поведения методов, которые были изменены в JDK ( currentClassLoader
, currentLoadedClass
, classLoaderDepth
, inClassLoader
).
Типичное использование этого метода в JDK, который должны были видеть менеджеры безопасности с 1.1 стилями, был ли там загрузчик class на стеке, и в противном случае обрабатывают код как "доверяющийся" и позволяет этому делать что-нибудь. Этот метод был изменен в JDK, чтобы позволить код JDK, которому доверяют (фактически любой предоставленный код java.security.AllPermission
) это вызывает doPrivileged
быть обработанным как доверяющийся менеджерами безопасности с 1.1 стилями. Это было также изменено, чтобы пропустить систему загрузчики class. Системный загрузчик class определяется как являющийся загрузчиком class, который равен системе загрузчик class (как возвращено ClassLoader.getSystemClassLoader) или один из его предков.
Этот метод возвратится null
в следующих трех случаях:
java.security.AllPermission
не приводит к SecurityException.Этот метод был осужден. Использовать checkPermission
вместо этого.
Этот метод был изменен тем же самым способом как currentClassLoader
, и возвратится null
если текущий контекст защиты предоставили AllPermission
или все методы на стеке (до первой привилегированной вызывающей стороны, если кто-либо) от классов, определенных, используя систему загрузчик class или один из его предков.
Этот метод был осужден. Использовать checkPermission
вместо этого.
Никакие изменения в поведении. Этот метод был осужден. Использовать checkPermission
вместо этого.
Этот метод был изменен тем же самым способом как currentClassLoader
, и возвратится -1
если текущий контекст защиты предоставили AllPermission
или все методы на стеке (до первой привилегированной вызывающей стороны, если кто-либо) от классов, определенных, используя систему загрузчик class или один из его предков.
Этот метод был осужден. Использовать checkPermission
вместо этого.
Никакие изменения в поведении. Этот метод был осужден. Использовать checkPermission
вместо этого.
Этот метод возвращает true если currentClassLoader
возвращает ненулевой загрузчик class, таким образом, он следует за той же самой семантикой что 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, так же как доступ к классам, у которых есть тот же самый загрузчик class как вызывающая сторона. Во всем другом вызове случаев checkPermission
с RuntimePermission("accessDeclaredMembers")
разрешение.
Если этот метод переопределяется, то звонок super.checkMemberAccess
не может быть сделан, как реализация по умолчанию checkMemberAccess
полагается на код, проверяемый, будучи в глубине стека 4. Например:
someCaller[3] java.lang.Class.someReflectionAPI [2] java.lang.Class.checkMemberAccess [1] SecurityManager.checkMemberAccess [0]Чтобы эмулировать это поведение, Вы должны были бы вызвать
getClassContext
, и исследуйте загрузчик class class в, индексируют 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, который все еще основан на глубине вызывающей стороны. Это должно позволить вызывающей стороне размышлять над классами от того же самого загрузчика class, из которого она прибыла.
Этот метод был изменен, чтобы создать a SecurityPermission
объект для данного разрешения предназначается для имени и вызовов checkPermission
с этим.
Если этот метод переопределяется, то звонок super.checkSecurityAccess
должен быть сделан в точке, переопределенный метод обычно выдавал бы исключение. Например:
public class MySecurityManager extends SecurityManager { public void checkSecurityAccess(String target) { if (someCustomSecurityCheckFails()) { super.checkSecurityAccess(target); } } }
Этот метод не был изменен.