java.lang.SecurityManager as the Default Security
ManagerThe Java SE JDK security architecture is policy-based, and allows for fine-grained access control. When code is loaded, it is assigned "permissions" based on the security policy currently in effect. Each permission specifies a permitted access to a particular resource, such as "read" and "write" access to a specified file or directory, or "connect" access to a given host and port. The policy, specifying which permissions are available for code from various signers/locations, can be initialized from an external configurable policy file. Unless a permission is explicitly granted to code, it cannot access the resource that is guarded by that permission. These new concepts of permission and policy enable the JDK to offer fine-grain, highly configurable, flexible, and extensible access control. Such access control can now not only be specified for applets, but also for all Java code, including applications, beans, and servlets.
For more information on the Java security architecture, please see the security documentaton.
The SecurityManager class contains many methods
with names that begin with the word check. Examples
are checkRead and checkConnect. Various
methods in the Java libraries call a check method
before performing each potentially security-sensitive operation.
The security manager is thereby given an opportunity to prevent
completion of the operation by throwing an exception. A security
manager routine simply returns if the operation is permitted, but
throws a SecurityException if the operation is not permitted. The
only exception to this convention is
checkTopLevelWindow, which returns a boolean
value.
The other main type of methods contained in the
SecurityManager class are those related to class
loader existence and depth:
java.lang.SecurityManager was an
abstract class. The default implementations of the security manager
check methods threw exceptions. The class loader and
depth-related classes were appropriately implemented, often in
native code.
Any application (such as a browser) that wanted to install a
security manager had to write their own, providing appropriate
concrete implementations of the methods that threw exceptions by
default -- primarily the check methods.
Security managers based on the JDK 1.1 applet security manager model typically based access control decisions on two things:
These types of decisions were made by calling the
SecurityManager methods related to class loader
existence and depth. For example, a typical 1.1-style security
manager might have a checkExit method like the
following:
public void checkExit(int status) {
if (inClassLoader()) {
throw new SecurityException(..);
}
}
Such a checkExit method would not allow
Runtime.exit to be called when any class defined with
a class loader (an applet) was on the stack. This is an example of
the first case, checking whether or not a class with a class loader
is on the stack. An example of the second case (class loader depth)
would be something like:
public void checkCreateClassLoader() {
if (classLoaderDepth() == 2) {
throw new SecurityException();
}
}
This method is saying that the class loader depth can't be 2.
That is, the method that called the method that called
checkCreateClassLoader must not be in a class defined
with a class loader. For example, the constructor for
java.lang.ClassLoader calls
checkCreateClassLoader, which means the method that
calls the constructor for java.lang.ClassLoader must
not have a class loader. This means applets can't directly create
class loaders.
Note that there is a big difference between the two methods,
even though both attempt to prevent applets from performing
actions. In the first case, checkExit will throw an
exception if an applet is anywhere on the stack. That means even
built-in JDK code can't exit the VM if it was called from an
applet. In the second case, JDK code is allowed to create a class
loader, even if it was called by an applet. That is because the
depth of a class with a class loader is used, and not the fact that
there is one.
java.lang.SecurityManager had a
number of changes made to it in order to allow it to be used as the
default security manager for applications. In particular:
abstract class, and can thus be
installed as-is.check methods call a new
checkPermission method, which by default calls the
method of the same name (checkPermission) in the new
AccessController class. Those methods that don't call
checkPermission have reasonable defaults.java.security.AllPermission.java.lang.SecurityManager as the Default Security
ManagerSince java.lang.SecurityManager is no longer
abstract, you can install and use it as the default security
manager. You can do this by setting a system property when
launching the VM:
java -Djava.security.manager YourApp
Alternatively, your application can install it directly via the
following line of code:
System.setSecurityManager(new SecurityManager());
You can customize the behavior of the default security manager by
modifying policy files. See the security guide on policy files for more information.
In the JDK, the SecurityManager methods related to
class loaders and class loader depth are not called by any
of the check methods, and they are deprecated. They
should not be used by any new security managers, and it is
recommended that their use be eliminated from existing security
managers as well. However, they are left in for backward
compatibility and they have been modified in an attempt to enable
old 1.1-style security managers to still work under the JDK,
without modification.
These methods are:
The class loader/depth related methods have all been modified in three ways:
ClassLoader.getSystemClassLoader) or one of its
ancestors.
Since classes loaded by the system class loader include
application classes (loaded off of CLASSPATH),
extension classes, and the built-in JDK classes, this modification
enables these methods to ignore such code.
Note that if you run an application that installs a custom
security manager, and that security manager is loaded off of
CLASSPATH in the JDK, it will have a system class
loader associated with it. (Application classes did not have a
class loader in JDK 1.1.) If you were to call a method like
classLoaderDepth from within the custom security
manager, and that method were not modified to ignore classes loaded
by a system class loader, it would always return 0, which would not
be very useful. Similarly, if class loader methods weren't changed
to skip system classes and a custom security manager was loaded off
of CLASSPATH, then this might also open up security
holes in cases where the security manager is making decisions based
on, for example, disallowing an operation if "classLoaderDepth() ==
2". (It should really be "classLoaderDepth() <= 2".)
AllPermission as if there is no class loader on the
stack.As an example of the use of the first two modifications, note
that there are now places in the JDK that open files, etc., after a
security manager has been installed. Some 1.1-style security
managers have a checkRead method that looks like the
following:
public void checkRead(String file) {
if (inClassLoader()) {
throw new SecurityException(..);
}
}
Without JDK code modifications, such a check run in the JDK
would cause a security exception to be thrown when the JDK itself
tries to read a file and there is a class with a non-system class
loader on the stack. With the new security model, all such JDK code
that tries to perform an operation that its caller might not be
allowed to do has a doPrivileged block around it.
Since inClassLoader just examines the stack up to and
including the frame containing the "privileged" code, and the code
at the top of the stack is JDK code, which is loaded by the system
class loader or one of its ancestors, the
inClassLoader method will return false,
allowing the read to occur.
As noted previously, security managers based on the 1.1 applet
security manager based some of their access control decisions on
class loader depth. As an example, the
checkCreateClassLoader method previously presented is
repeated here:
public void checkCreateClassLoader() {
if (classLoaderDepth() == 2) {
throw new SecurityException();
}
}
In the JDK we have attempted to maintain the stack depth as used in
1.1-style security managers. For example, the constructor for
java.security.SecureClassLoader has an explicit call to
SecurityManager.checkCreateClassLoader even though the
constructor for its super class (ClassLoader) also does. If the
check was not placed in the constructor for
SecureClassLoader, then a 1.1-style security manager
would allow untrusted code to extend SecureClassLoader
and construct class loaders, as the class loader depth would always
be greater than 2.
First and foremost, we highly recommend analyzing all your custom security manager methods before running your security manager under the JDK. Failure to do so could result in a security hole or prevent the proper operation of the JDK. This is due to the fragile nature of 1.1-style security managers.
Where possible, you should just use the default implementation
of the 1.2 SecurityManager. This helps give users and
administrators consistent behavior. If this is not possible, then
you should at least try to call super.checkXXX in your
checkXXX method before throwing a security exception.
Doing so will allow the access controller algorithm to be used, and
will allow the JDK itself to function correctly.
In the JDK, any existing code that used to call any of the
SecurityManager check methods continues to do so. For
new code that requires a security check, calls are made to
SecurityManager.checkPermission instead of adding a
new SecurityManager check method. For example, the new
java.lang.System.setProperty method calls
checkPermission with a
java.util.PropertyPermission permission.
When extending the SecurityManager class and overriding existing
methods, some care should be taken. For example, if you override
the checkRead(String file) method so it always throws
a security exception, then the JDK itself may fail to operate
properly. That is, if some JDK code needs to open a file (to read a
properties file, load a JAR file, etc.) then throwing a security
exception for every read attempt would cause such opens to always
fail.
In general, you should only override the default methods if
you intend to loosen security, not to make it stronger. If
you want to tighten security, you should modify the default
policy files and/or install a custom
java.security.Policy object. See the security
guide on policy files for more
information.
In general, when overriding security manager methods you should
place a call to the super.checkXXX method at the point
where your overridden checkXXX method would throw an
exception. For example:
public class MySecurityManager extends SecurityManager {
public void checkRead(String file) {
if (someCustomSecurityCheckFails()) {
super.checkRead(file);
}
}
}
If your custom security check fails, then
super.checkRead gets called. The default
implementation of checkRead invokes
checkPermission, which by default consults the
AccessController. By invoking the
AccessController, system code that has done an
AccessController.doPrivileged before trying to read a
file will succeed in reading that file. All other code will be
subjected to the current policy in effect, and an access control
exception will be thrown if access to that file has not been
granted.
Note, there are some checkXXX methods in which you
should not call super.checkXXX methods when
overriding them. That is because the default implementation of
these methods may not be as strict as the policy you are
implementing in the overridden method. For example, the default
checkAccess(ThreadGroup g) method only protects the
system thread group. If you intend to protect threads in distinct
thread groups from each other (for example applet thread groups),
then you would not want to call super.checkAccess at
the point you would normally throw a security exception, as that
would defeat the purpose of your customized check. Instead, you
could place a call to super.checkAccess as the first
statement in your overridden method.
For example:
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.
...
}
We describe how to override each method in the following section.
java.lang.SecurityManager methods in the JDK and
provides suggestions regarding any overrides you may wish to make.
Please see the Java documentation for the
SecurityManager class for more information on these
methods.
This field has been deprecated, and any uses of this field
within the JDK itself have been removed. Instead of using inCheck,
you should use checkPermission along with
doPrivileged.
This method has also been deprecated.
The constructor has been modified to allow multiple
SecurityManagers to be created, assuming the caller has the
RuntimePermission("createSecurityManager")
permission.
No changes. This call can be used to emulate the 1.1 behavior of
the methods that have been changed in the JDK (
currentClassLoader, currentLoadedClass,
classLoaderDepth, inClassLoader).
The typical use of this method in JDK 1.1-style security
managers was to see if there was a class loader on the stack, and
if not, treat the code as "trusted" and allow it to do anything.
This method has been modified in the JDK to allow trusted JDK code
(actually any code granted
java.security.AllPermission) that calls
doPrivileged to be treated as trusted by 1.1-style
security managers. It has also been modified to skip system class
loaders. A system class loader is defined as being a class loader
that is equal to the system class loader (as returned by
ClassLoader.getSystemClassLoader) or one of its ancestors.
This method will return null in the following three
cases:
java.security.AllPermission does not result in
a SecurityException.This method has been deprecated. Use
checkPermission instead.
This method has been modified in the same fashion as
currentClassLoader, and will return null
if the current security context has been granted
AllPermission or all the methods on the stack (up to
the first privileged caller, if any) are from classes defined using
the system class loader or one of its ancestors.
This method has been deprecated. Use
checkPermission instead.
No changes in behavior. This method has been deprecated. Use
checkPermission instead.
This method has been modified in the same fashion as
currentClassLoader, and will return -1 if
the current security context has been granted
AllPermission or all the methods on the stack (up to
the first privileged caller, if any) are from classes defined using
the system class loader or one of its ancestors.
This method has been deprecated. Use
checkPermission instead.
No changes in behavior. This method has been deprecated. Use
checkPermission instead.
This method returns true if currentClassLoader
returns a non-null class loader, so it follows the same semantics
that currentClassLoader does.
This method has been deprecated. Use
checkPermission instead.
This method returns a
java.security.AccessControlContext object that is
created with a call to
java.security.AccessController.getContext. In JDK1.1
it returned null by default.
This method is new in the JDK. It calls
java.security.AccessController.checkPermission with
the given permission. Internally, the JDK always calls
SecurityManager.checkPermission instead of calling the
AccessController directly. This allows people to
override this method to provide additional functionality such as
auditing and/or GUI dialogs.
This method is new in the JDK. If context is an
instance of AccessControlContext then the
AccessControlContext.checkPermission method will be
invoked on the given context with the specified permission.
If context is not an instance of
AccessControlContext then a
SecurityException is thrown.
This method has been modified to call
checkPermission with the
RuntimePermission("createClassLoader") permission.
If this method is overridden, then a call to
super.checkCreateClassLoader should be made at the
point the overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkCreateClassLoader() {
if (someCustomSecurityCheckFails()) {
super.checkCreateClassLoader();
}
}
}
If the thread argument is a system thread (belongs to the thread
group with a null parent) then this method calls
checkPermission with the
RuntimePermission("modifyThread") permission.
Applications that want a stricter policy should override this method.
If this method is overridden, then
super.checkAccess should be called by the first
statement in the overridden method, or the equivalent security
check should be placed in the overridden method.
If this method is overridden, the method that overrides it
should additionally check to see if the calling thread has the
RuntimePermission("modifyThread") permission, and if
so, return silently. This is to ensure that code granted that
permission (such as the JDK itself) is allowed to manipulate any
thread.
For example:
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"));
}
...
}
}
If the thread group argument is the system thread group (has a
null parent) then this method calls
checkPermission with the
RuntimePermission("modifyThreadGroup") permission.
Applications that want a stricter policy should override this method.
If this method is overridden, then
super.checkAccess should be called by the first
statement in the overridden method, or the equivalent security
check should be placed in the overridden method.
If this method is overridden, the method that overrides it
should additionally check to see if the caller has the
RuntimePermission("modifyThreadGroup") permission, and
if so, return silently. This is to ensure that code granted that
permission (such as the JDK itself) is allowed to manipulate any
thread group.
For example:
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"));
}
...
}
}
This method has been modified to call
checkPermission with the
RuntimePermission("exitVM") permission.
If this method is overridden, then a call to
super.checkExit should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkExit(int status) {
if (someCustomSecurityCheckFails()) {
super.checkExit(status);
}
}
}
This method has been modified to call
checkPermission with a FilePermission. If
the cmd is an absolute path (see
java.io.File.isAbsolute) then it is passed as-is as
the target for the FilePermission. If cmd
is not absolute, then the special target "<<ALL
FILES>>" is used. This target is used because it is difficult
to determine the actual path of the command that will be executed
on an individual platform due to things such as environment
variables, etc.
If this method is overridden, then a call to
super.checkExec should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkExec(String cmd) {
if (someCustomSecurityCheckFails()) {
super.checkExec(cmd);
}
}
}
This method has been modified to call
checkPermission with the
RuntimePermission("loadLibrary."+lib) permission.
If this method is overridden, then a call to
super.checkLink should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkLink(String lib) {
if (someCustomSecurityCheckFails()) {
super.checkLink(lib);
}
}
}
This method has been modified to call
checkPermission with the
RuntimePermission("readFileDescriptor")
permission.
If this method is overridden, then a call to
super.checkRead should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkRead(FileDescriptor fd) {
if (someCustomSecurityCheckFails()) {
super.checkRead(fd);
}
}
}
This method has been modified to call
checkPermission with the
FilePermission(file,"read") permission.
If this method is overridden, then a call to
super.checkRead should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkRead(String file) {
if (someCustomSecurityCheckFails()) {
super.checkRead(file);
}
}
}
This method has been modified. If context is an
instance of AccessControlContext then the
AccessControlContext.checkPermission method will be
invoked on the given context with the
FilePermission(file,"read") permission.
If context is not an instance of
AccessControlContext then a
SecurityException is thrown.
If this method is overridden, then a call to
super.checkRead should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkRead(String file, Object context) {
if (someCustomSecurityCheckFails()) {
super.checkRead(file, context);
}
}
}
This method has been modified to call
checkPermission with the
RuntimePermission("writeFileDescriptor")
permission.
If this method is overridden, then a call to
super.checkWrite should be made at the point the
overridden method would normally throw an exception. For
Example:
public class MySecurityManager extends SecurityManager {
public void checkWrite(FileDescriptor fd) {
if (someCustomSecurityCheckFails()) {
super.checkWrite(fd);
}
}
}
This method has been modified to call
checkPermission with the
FilePermission(file,"write") permission.
If this method is overridden, then a call to
super.checkWrite should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkWrite(String file) {
if (someCustomSecurityCheckFails()) {
super.checkWrite(file);
}
}
}
This method has been modified to call
checkPermission with the
FilePermission(file,"delete") permission.
If this method is overridden, then a call to
super.checkDelete should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkDelete(String file) {
if (someCustomSecurityCheckFails()) {
super.checkDelete(file);
}
}
}
This method has been modified to call
checkPermission with the
SocketPermission(host+":"+port,"connect") permission
if the port is not equal to -1. If the port is equal to -1, then it
calls checkPermission with the
SocketPermission(host,"resolve") permission.
This behavior is consistent with JDK 1.1, where a port equal to -1 indicates that an IP address lookup is being performed.
If this method is overridden, then a call to
super.checkConnect should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkConnect(String host, int port) {
if (someCustomSecurityCheckFails()) {
super.checkConnect(host, port);
}
}
}
This method has been modified. If context is an
instance of AccessControlContext then the
AccessControlContext.checkPermission method will be
invoked on the given context with the
SocketPermission(host+":"+port,"connect") permission
if the port is not equal to -1. If the port is equal to -1, then it
calls checkPermission with the
SocketPermission(host,"resolve") permission.
If context is not an instance of
AccessControlContext then a
SecurityException is thrown.
If this method is overridden, then a call to
super.checkConnect should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkConnect(String host, int port, Object context) {
if (someCustomSecurityCheckFails()) {
super.checkConnect(host, port, context);
}
}
}
This method has been modified. If port is not 0, it calls
checkPermission with the
SocketPermission("localhost:"+port,"listen"). If port
is zero, it calls checkPermission with
SocketPermission("localhost:1024-","listen").
If this method is overridden, then a call to
super.checkListen should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkListen(int port) {
if (someCustomSecurityCheckFails()) {
super.checkListen(port);
}
}
}
This method has been modified to call
checkPermission with the
SocketPermission(host+":"+port,"accept")
permission.
If this method is overridden, then a call to
super.checkAccept should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkAccept(String host, int port) {
if (someCustomSecurityCheckFails()) {
super.checkAccept(host, port);
}
}
}
This method has been modified to call
checkPermission with the
SocketPermission(maddr.getHostAddress(),"accept,connect")
permission.
If this method is overridden, then a call to
super.checkMulticast should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkMultiCast(InetAddress maddr) {
if (someCustomSecurityCheckFails()) {
super.checkMultiCast(maddr);
}
}
}
This method has been modified to call
checkPermission with the
SocketPermission(maddr.getHostAddress(),"accept,connect")
permission.
If this method is overridden, then a call to
super.checkMulticast should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkMultiCast(InetAddress maddr, byte ttl) {
if (someCustomSecurityCheckFails()) {
super.checkMultiCast(maddr, ttl);
}
}
}
This method has been modified to call
checkPermission with the PropertyPermission("*",
"read,write") permission.
If this method is overridden, then a call to
super.checkPropertiesAccess should be made at the
point the overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkPropertiesAccess() {
if (someCustomSecurityCheckFails()) {
super.checkPropertiesAccess();
}
}
}
This method has been modified to call
checkPermission with the PropertyPermission(key,
"read") permission.
If this method is overridden, then a call to
super.checkPropertyAccess should be made at the point
the overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkPropertyAccess(String key) {
if (someCustomSecurityCheckFails()) {
super.checkPropertiesAccess(key);
}
}
}
This method has been modified to call
checkPermission with the
AWTPermission("showWindowWithoutWarningBanner")
permission, and returns true if an SecurityException is not thrown,
otherwise it returns false.
If this method is overridden, then a call to
super.checkTopLevelWindow should be made at the point
the overridden method would normally return false, and the value of
super.checkTopLevelWindow should be returned. For
example:
public class MySecurityManager extends SecurityManager {
public void checkTopLevelWindow(Object window) {
if (someCustomSecurityCheckFails()) {
return super.checkTopLevelWindow(window);
} else {
return true;
}
}
}
This method has been modified to call
checkPermission with the
RuntimePermission("queuePrintJob") permission.
If this method is overridden, then a call to
super.checkPrintJobAccess should be made at the point
the overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkPrintJobAccess() {
if (someCustomSecurityCheckFails()) {
super.checkPrintJobAccess();
}
}
}
This method has been modified to call
checkPermission with the
AWTPermission("accessClipboard") permission.
If this method is overridden, then a call to
super.checkSystemClipboardAccess should be made at the
point the overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkSystemClipboardAccess() {
if (someCustomSecurityCheckFails()) {
super.checkSystemClipboardAccess();
}
}
}
This method has been modified to call
checkPermission with the
AWTPermission("accessEventQueue") permission.
If this method is overridden, then a call to
super.checkAwtEventQueueAccess should be made at the
point the overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkAwtEventQueueAccess() {
if (someCustomSecurityCheckFails()) {
super.checkAwtEventQueueAccess();
}
}
}
This method has been modified. It first gets a list of
restricted packages by obtaining a comma-separated list from a call
to
java.security.Security.getProperty("package.access"),
and checks to see if pkg starts with or equals any of
the restricted packages. If it does, then
checkPermission gets called with the
RuntimePermission("accessClassInPackage."+pkg)
permission.
If this method is overridden, then
super.checkPackageAccess should be called as the first
line in the overridden method. For example:
public class MySecurityManager extends SecurityManager {
public void checkPackageAccess(String pkg) {
super.checkPackageAccess(pkg);
...
someCustomSecurityCheck();
...
}
}
This method has been modified. It first gets a list of
restricted packages by obtaining a comma-separated list from a call
to
java.security.Security.getProperty("package.definition"),
and checks to see if pkg starts with or equals any of
the restricted packages. If it does, then
checkPermission gets called with the
RuntimePermission("defineClassInPackage."+pkg)
permission.
If this method is overridden, then
super.checkPackageDefinition should be called as the
first line in the overridden method. For example:
public class MySecurityManager extends SecurityManager {
public void checkPackageDefinition(String pkg) {
super.checkPackageDefinition(pkg);
...
someCustomSecurityCheck();
...
}
}
This method has been modified to call
checkPermission with the
RuntimePermission("setFactory") permission.
If this method is overridden, then a call to
super.checkSetFactory should be made at the point the
overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkSetFactory() {
if (someCustomSecurityCheckFails()) {
super.checkSetFactory();
}
}
}
This method has been modified. The default policy is to allow
access to PUBLIC members, as well as access to classes that have
the same class loader as the caller. In all other cases call
checkPermission with the
RuntimePermission("accessDeclaredMembers")
permission.
If this method is overridden, then a call to
super.checkMemberAccess cannot be made, as the default
implementation of checkMemberAccess relies on the code
being checked being at a stack depth of 4. For example:
someCaller[3]
java.lang.Class.someReflectionAPI [2]
java.lang.Class.checkMemberAccess [1]
SecurityManager.checkMemberAccess [0]
In order to emulate this behavior, you would need to call
getClassContext, and examine the class loader of the
class at index 3, just as the default
checkMemberAccess method does:
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);
}
}
This is the only security manager method in the JDK that is still based on a caller's depth. This is to allow a caller to reflect on classes from the same class loader it came from.
This method has been modified to create a
SecurityPermission object for the given permission
target name and calls checkPermission with it.
If this method is overridden, then a call to
super.checkSecurityAccess should be made at the point
the overridden method would normally throw an exception. For
example:
public class MySecurityManager extends SecurityManager {
public void checkSecurityAccess(String target) {
if (someCustomSecurityCheckFails()) {
super.checkSecurityAccess(target);
}
}
}
This method has not been changed.
