The SecurityManager class contains many methods with
names that begin with the word check. These methods
are called by various methods in the Java libraries before those
methods perform certain potentially sensitive operations. The
invocation of such a check method typically looks like this:
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkXXX(argument, . . . );
}
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 current security manager is set by the
setSecurityManager method in class
System. The current security manager is obtained
by the getSecurityManager method.
The special method determines whether an access request indicated by a specified permission should be granted or denied. The default implementation calls
AccessController.checkPermission(perm);
If a requested access is allowed,
checkPermission returns quietly. If denied, a
SecurityException is thrown.
As of Java 2 SDK v1.2, the default implementation of each of the other
check methods in SecurityManager is to
call the SecurityManager checkPermission method
to determine if the calling thread has permission to perform the requested
operation.
Note that the checkPermission method with
just a single permission argument always performs security checks
within the context of the currently executing thread.
Sometimes a security check that should be made within a given context
will actually need to be done from within a
different context (for example, from within a worker thread).
The getSecurityContext
method
and the checkPermission
method that includes a context argument are provided
for this situation. The
getSecurityContext method returns a "snapshot"
of the current calling context. (The default implementation
returns an AccessControlContext object.) A sample call is
the following:
Object context = null; SecurityManager sm = System.getSecurityManager(); if (sm != null) context = sm.getSecurityContext();
The checkPermission method
that takes a context object in addition to a permission
makes access decisions based on that context,
rather than on that of the current execution thread.
Code within a different context can thus call that method,
passing the permission and the
previously-saved context object. A sample call, using the
SecurityManager sm obtained as in the previous example,
is the following:
if (sm != null) sm.checkPermission(permission, context);
Permissions fall into these categories: File, Socket, Net,
Security, Runtime, Property, AWT, Reflect, and Serializable.
The classes managing these various
permission categories are java.io.FilePermission,
java.net.SocketPermission,
java.net.NetPermission,
java.security.SecurityPermission,
java.lang.RuntimePermission,
java.util.PropertyPermission,
java.awt.AWTPermission,
java.lang.reflect.ReflectPermission, and
java.io.SerializablePermission.
All but the first two (FilePermission and SocketPermission) are
subclasses of java.security.BasicPermission, which itself
is an abstract subclass of the
top-level class for permissions, which is
java.security.Permission. BasicPermission defines the
functionality needed for all permissions that contain a name
that follows the hierarchical property naming convention
(for example, "exitVM", "setFactory", "queuePrintJob", etc).
An asterisk
may appear at the end of the name, following a ".", or by itself, to
signify a wildcard match. For example: "a.*" or "*" is valid,
"*a" or "a*b" is not valid.
FilePermission and SocketPermission are subclasses of the
top-level class for permissions
(java.security.Permission). Classes like these
that have a more complicated name syntax than that used by
BasicPermission subclass directly from Permission rather than from
BasicPermission. For example,
for a java.io.FilePermission object, the permission name is
the path name of a file (or directory).
Some of the permission classes have an "actions" list that tells
the actions that are permitted for the object. For example,
for a java.io.FilePermission object, the actions list
(such as "read, write") specifies which actions are granted for the
specified file (or for files in the specified directory).
Other permission classes are for "named" permissions - ones that contain a name but no actions list; you either have the named permission or you don't.
Note: There is also a java.security.AllPermission
permission that implies all permissions. It exists to simplify the work
of system administrators who might need to perform multiple
tasks that require all (or numerous) permissions.
See
Permissions in the JDK for permission-related information.
This document includes, for example, a table listing the various SecurityManager
check methods and the permission(s) the default
implementation of each such method requires.
It also contains a table of all the version 1.2 methods
that require permissions, and for each such method tells
which permission it requires.
For more information about SecurityManager changes made in
the JDK and advice regarding porting of 1.1-style security managers,
see the security documentation.
SecurityManager.
If there is a security manager already installed, this method first
calls the security manager's checkPermission method
with the RuntimePermission("createSecurityManager")
permission to ensure the calling thread has permission to create a new
security manager.
This may result in throwing a SecurityException.
SecurityException if the
calling thread is not permitted to accept a socket connection from
the specified host and port number.
This method is invoked for the current security manager by the
accept method of class ServerSocket.
This method calls checkPermission with the
SocketPermission(host+":"+port,"accept") permission.
If you override this method, then you should make a call to
super.checkAccept
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to modify the thread argument.
This method is invoked for the current security manager by the
stop, suspend, resume,
setPriority, setName, and
setDaemon methods of class Thread.
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.
If the thread argument is not a system thread,
this method just returns silently.
Applications that want a stricter policy should override this
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.
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.
SecurityException if the
calling thread is not allowed to modify the thread group argument.
This method is invoked for the current security manager when a
new child thread or child thread group is created, and by the
setDaemon, setMaxPriority,
stop, suspend, resume, and
destroy methods of class ThreadGroup.
If the thread group argument is the system thread group (
has a null parent) then
this method calls checkPermission with the
RuntimePermission("modifyThreadGroup") permission.
If the thread group argument is not the system thread group,
this method just returns silently.
Applications that want a stricter policy should override this
method. If this method is overridden, the method that overrides
it should additionally check to see if the calling thread 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.
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.
SecurityException if the
calling thread is not allowed to access the AWT event queue.
This method calls checkPermission with the
AWTPermission("accessEventQueue") permission.
If you override this method, then you should make a call to
super.checkAwtEventQueueAccess
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to open a socket connection to the
specified host and port number.
A port number of -1 indicates that the calling
method is attempting to determine the IP address of the specified
host name.
This method calls 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.
If you override this method, then you should make a call to
super.checkConnect
at the point the overridden method would normally throw an
exception.
SecurityException if the
specified security context is not allowed to open a socket
connection to the specified host and port number.
A port number of -1 indicates that the calling
method is attempting to determine the IP address of the specified
host name.
If context is not an instance of
AccessControlContext then a
SecurityException is thrown.
Otherwise, the port number is checked. If it is not equal
to -1, the context's checkPermission
method is called with a
SocketPermission(host+":"+port,"connect") permission.
If the port is equal to -1, then
the context's checkPermission method
is called with a
SocketPermission(host,"resolve") permission.
If you override this method, then you should make a call to
super.checkConnect
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to create a new class loader.
This method calls checkPermission with the
RuntimePermission("createClassLoader")
permission.
If you override this method, then you should make a call to
super.checkCreateClassLoader
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to delete the specified file.
This method is invoked for the current security manager by the
delete method of class File.
This method calls checkPermission with the
FilePermission(file,"delete") permission.
If you override this method, then you should make a call to
super.checkDelete
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to create a subprocess.
This method is invoked for the current security manager by the
exec methods of class Runtime.
This method calls checkPermission with the
FilePermission(cmd,"execute") permission
if cmd is an absolute path, otherwise it calls
checkPermission with
FilePermission("<<ALL FILES>>","execute").
If you override this method, then you should make a call to
super.checkExec
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to cause the Java Virtual Machine to
halt with the specified status code.
This method is invoked for the current security manager by the
exit method of class Runtime. A status
of 0 indicates success; other values indicate various
errors.
This method calls checkPermission with the
RuntimePermission("exitVM") permission.
If you override this method, then you should make a call to
super.checkExit
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to dynamic link the library code
specified by the string argument file. The argument is either a
simple library name or a complete filename.
This method is invoked for the current security manager by
methods load and loadLibrary of class
Runtime.
This method calls checkPermission with the
RuntimePermission("loadLibrary."+lib) permission.
If you override this method, then you should make a call to
super.checkLink
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to wait for a connection request on
the specified local port number.
If port is not 0, this method calls
checkPermission with the
SocketPermission("localhost:"+port,"listen").
If port is zero, this method calls checkPermission
with SocketPermission("localhost:1024-","listen").
If you override this method, then you should make a call to
super.checkListen
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to access members.
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, this method calls 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.
SecurityException if the
calling thread is not allowed to use
(join/leave/send/receive) IP multicast.
This method calls checkPermission with the
java.net.SocketPermission(maddr.getHostAddress(),
"accept,connect") permission.
If you override this method, then you should make a call to
super.checkMulticast
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to use
(join/leave/send/receive) IP multicast.
This method calls checkPermission with the
java.net.SocketPermission(maddr.getHostAddress(),
"accept,connect") permission.
If you override this method, then you should make a call to
super.checkMulticast
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to access the package specified by
the argument.
This method is used by the loadClass method of class
loaders.
This method 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.
SecurityException if the
calling thread is not allowed to define classes in the package
specified by the argument.
This method is used by the loadClass method of some
class loaders.
This method 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.
SecurityException if the requested
access, specified by the given permission, is not permitted based
on the security policy currently in effect.
This method calls AccessController.checkPermission
with the given permission.
SecurityException if the
specified security context is denied access to the resource
specified by the given permission.
The context must be a security
context returned by a previous call to
getSecurityContext and the access control
decision is based upon the configured security policy for
that security context.
If context is an instance of
AccessControlContext then the
AccessControlContext.checkPermission method is
invoked with the specified permission.
If context is not an instance of
AccessControlContext then a
SecurityException is thrown.
SecurityException if the
calling thread is not allowed to initiate a print job request.
This method calls
checkPermission with the
RuntimePermission("queuePrintJob") permission.
If you override this method, then you should make a call to
super.checkPrintJobAccess
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to access or modify the system
properties.
This method is used by the getProperties and
setProperties methods of class System.
This method calls checkPermission with the
PropertyPermission("*", "read,write") permission.
If you override this method, then you should make a call to
super.checkPropertiesAccess
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to access the system property with
the specified key name.
This method is used by the getProperty method of
class System.
This method calls checkPermission with the
PropertyPermission(key, "read") permission.
If you override this method, then you should make a call to
super.checkPropertyAccess
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to read from the specified file
descriptor.
This method calls checkPermission with the
RuntimePermission("readFileDescriptor")
permission.
If you override this method, then you should make a call to
super.checkRead
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to read the file specified by the
string argument.
This method calls checkPermission with the
FilePermission(file,"read") permission.
If you override this method, then you should make a call to
super.checkRead
at the point the overridden method would normally throw an
exception.
SecurityException if the
specified security context is not allowed to read the file
specified by the string argument. The context must be a security
context returned by a previous call to
getSecurityContext.
If context is an instance of
AccessControlContext then the
AccessControlContext.checkPermission method will
be invoked with the FilePermission(file,"read") permission.
If context is not an instance of
AccessControlContext then a
SecurityException is thrown.
If you override this method, then you should make a call to
super.checkRead
at the point the overridden method would normally throw an
exception.
If the requested permission is allowed, this method returns quietly. If denied, a SecurityException is raised.
This method creates a SecurityPermission object for
the given permission target name and calls checkPermission
with it.
See the documentation for
java.security.SecurityPermission
for
a list of possible permission target names.
If you override this method, then you should make a call to
super.checkSecurityAccess
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to set the socket factory used by
ServerSocket or Socket, or the stream
handler factory used by URL.
This method calls checkPermission with the
RuntimePermission("setFactory") permission.
If you override this method, then you should make a call to
super.checkSetFactory
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to access the system clipboard.
This method calls checkPermission with the
AWTPermission("accessClipboard")
permission.
If you override this method, then you should make a call to
super.checkSystemClipboardAccess
at the point the overridden method would normally throw an
exception.
false if the calling
thread is not trusted to bring up the top-level window indicated
by the window argument. In this case, the caller can
still decide to show the window, but the window should include
some sort of visual warning. If the method returns
true, then the window can be shown without any
special restrictions.
See class Window for more information on trusted and
untrusted windows.
This method calls
checkPermission with the
AWTPermission("showWindowWithoutWarningBanner") permission,
and returns true if a SecurityException is not thrown,
otherwise it returns false.
If you override this method, then you should make a call to
super.checkTopLevelWindow
at the point the overridden method would normally return
false, and the value of
super.checkTopLevelWindow should
be returned.
SecurityException if the
calling thread is not allowed to write to the specified file
descriptor.
This method calls checkPermission with the
RuntimePermission("writeFileDescriptor")
permission.
If you override this method, then you should make a call to
super.checkWrite
at the point the overridden method would normally throw an
exception.
SecurityException if the
calling thread is not allowed to write to the file specified by
the string argument.
This method calls checkPermission with the
FilePermission(file,"write") permission.
If you override this method, then you should make a call to
super.checkWrite
at the point the overridden method would normally throw an
exception.
The equals method implements an equivalence relation
on non-null object references:
x, x.equals(x) should return
true.
x and y, x.equals(y)
should return true if and only if
y.equals(x) returns true.
x, y, and z, if
x.equals(y) returns true and
y.equals(z) returns true, then
x.equals(z) should return true.
x and y, multiple invocations of
x.equals(y) consistently return true
or consistently return false, provided no
information used in equals comparisons on the
objects is modified.
x,
x.equals(null) should return false.
The equals method for class Object implements
the most discriminating possible equivalence relation on objects;
that is, for any non-null reference values x and
y, this method returns true if and only
if x and y refer to the same object
(x == y has the value true).
Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.
checkConnect method and by the
two-argument checkRead method.
These methods are needed because a trusted method may be called
on to read a file or open a socket on behalf of another method.
The trusted method needs to determine if the other (possibly
untrusted) method would be allowed to perform the operation on its
own.
The default implementation of this method is to return
an AccessControlContext object.
java.util.Hashtable.
The general contract of hashCode is:
hashCode method on each of
the two objects must produce the same integer result.
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)
wait methods.
The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:
synchronized statement
that synchronizes on the object.
Class, by executing a
synchronized static method of that class.
Only one thread at a time can own an object's monitor.
wait methods.
The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.
toString method returns a string that
"textually represents" this object. The result should
be a concise but informative representation that is easy for a
person to read.
It is recommended that all subclasses override this method.
The toString method for class Object
returns a string consisting of the name of the class of which the
object is an instance, the at-sign character `@', and
the unsigned hexadecimal representation of the hash code of the
object. In other words, this method returns a string equal to the
value of:
getClass().getName() + '@' + Integer.toHexString(hashCode())
The current thread must own this object's monitor. The thread
releases ownership of this monitor and waits until another thread
notifies threads waiting on this object's monitor to wake up
either through a call to the notify method or the
notifyAll method. The thread then waits until it can
re-obtain ownership of the monitor and resumes execution.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.The current thread must own this object's monitor.
This method causes the current thread (call it T) to place itself in the wait set for this object and then to relinquish any and all synchronization claims on this object. Thread T becomes disabled for thread scheduling purposes and lies dormant until one of four things happens:
A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout);
... // Perform action appropriate to condition
}
(For more information on this topic, see Section 3.2.3 in Doug Lea's
"Concurrent Programming in Java (Second Edition)" (Addison-Wesley,
2000), or Item 50 in Joshua Bloch's "Effective Java Programming
Language Guide" (Addison-Wesley, 2001).
If the current thread is interrupted by another thread while it is waiting, then an InterruptedException is thrown. This exception is not thrown until the lock status of this object has been restored as described above.
Note that the wait method, as it places the current thread into the wait set for this object, unlocks only this object; any other objects on which the current thread may be synchronized remain locked while the thread waits.
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.
This method is similar to the wait method of one
argument, but it allows finer control over the amount of time to
wait for a notification before giving up. The amount of real time,
measured in nanoseconds, is given by:
1000000*timeout+nanos
In all other respects, this method does the same thing as the method of one argument. In particular, wait(0, 0) means the same thing as wait(0).
The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until either of the following two conditions has occurred:
notify method
or the notifyAll method.
timeout
milliseconds plus nanos nanoseconds arguments, has
elapsed.
The thread then waits until it can re-obtain ownership of the monitor and resumes execution.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout, nanos);
... // Perform action appropriate to condition
}
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.