This class is for runtime permissions. A RuntimePermission contains a name (also referred to as a "target name") but no actions list; you either have the named permission or you don't.

The target name is the name of the runtime permission (see below). The naming convention follows the hierarchical property naming convention. Also, an asterisk may appear at the end of the name, following a ".", or by itself, to signify a wildcard match. For example: "loadLibrary.*" or "*" is valid, "*loadLibrary" or "a*b" is not valid.

The following table lists all the possible RuntimePermission target names, and for each provides a description of what the permission allows and a discussion of the risks of granting code the permission.

Permission Target Name What the Permission Allows Risks of Allowing this Permission
createClassLoader Creation of a class loader This is an extremely dangerous permission to grant. Malicious applications that can instantiate their own class loaders could then load their own rogue classes into the system. These newly loaded classes could be placed into any protection domain by the class loader, thereby automatically granting the classes the permissions for that domain.
getClassLoader Retrieval of a class loader (e.g., the class loader for the calling class) This would grant an attacker permission to get the class loader for a particular class. This is dangerous because having access to a class's class loader allows the attacker to load other classes available to that class loader. The attacker would typically otherwise not have access to those classes.
setContextClassLoader Setting of the context class loader used by a thread The context class loader is used by system code and extensions when they need to lookup resources that might not exist in the system class loader. Granting setContextClassLoader permission would allow code to change which context class loader is used for a particular thread, including system threads.
enableContextClassLoaderOverride Subclass implementation of the thread context class loader methods The context class loader is used by system code and extensions when they need to lookup resources that might not exist in the system class loader. Granting enableContextClassLoaderOverride permission would allow a subclass of Thread to override the methods that are used to get or set the context class loader for a particular thread.
setSecurityManager Setting of the security manager (possibly replacing an existing one) The security manager is a class that allows applications to implement a security policy. Granting the setSecurityManager permission would allow code to change which security manager is used by installing a different, possibly less restrictive security manager, thereby bypassing checks that would have been enforced by the original security manager.
createSecurityManager Creation of a new security manager This gives code access to protected, sensitive methods that may disclose information about other classes or the execution stack.
getenv.{variable name} Reading of the value of the specified environment variable This would allow code to read the value, or determine the existence, of a particular environment variable. This is dangerous if the variable contains confidential data.
exitVM Halting of the Java Virtual Machine This allows an attacker to mount a denial-of-service attack by automatically forcing the virtual machine to halt. Note: The "exitVM" permission is automatically granted to all code loaded from the application class path, thus enabling applications to terminate themselves.
shutdownHooks Registration and cancellation of virtual-machine shutdown hooks This allows an attacker to register a malicious shutdown hook that interferes with the clean shutdown of the virtual machine.
setFactory Setting of the socket factory used by ServerSocket or Socket, or of the stream handler factory used by URL This allows code to set the actual implementation for the socket, server socket, stream handler, or RMI socket factory. An attacker may set a faulty implementation which mangles the data stream.
setIO Setting of System.out, System.in, and System.err This allows changing the value of the standard system streams. An attacker may change System.in to monitor and steal user input, or may set System.err to a "null" OutputStream, which would hide any error messages sent to System.err.
modifyThread Modification of threads, e.g., via calls to Thread interrupt, stop, suspend, resume, setDaemon, setPriority, setName and setUncaughtExceptionHandler methods This allows an attacker to modify the behaviour of any thread in the system.
stopThread Stopping of threads via calls to the Thread stop method This allows code to stop any thread in the system provided that it is already granted permission to access that thread. This poses as a threat, because that code may corrupt the system by killing existing threads.
modifyThreadGroup modification of thread groups, e.g., via calls to ThreadGroup destroy, getParent, resume, setDaemon, setMaxPriority, stop, and suspend methods This allows an attacker to create thread groups and set their run priority.
getProtectionDomain Retrieval of the ProtectionDomain for a class This allows code to obtain policy information for a particular code source. While obtaining policy information does not compromise the security of the system, it does give attackers additional information, such as local file names for example, to better aim an attack.
readFileDescriptor Reading of file descriptors This would allow code to read the particular file associated with the file descriptor read. This is dangerous if the file contains confidential data.
writeFileDescriptor Writing to file descriptors This allows code to write to a particular file associated with the descriptor. This is dangerous because it may allow malicious code to plant viruses or at the very least, fill up your entire disk.
loadLibrary.{library name} Dynamic linking of the specified library It is dangerous to allow an applet permission to load native code libraries, because the Java security architecture is not designed to and does not prevent malicious behavior at the level of native code.
accessClassInPackage.{package name} Access to the specified package via a class loader's loadClass method when that class loader calls the SecurityManager checkPackageAccess method This gives code access to classes in packages to which it normally does not have access. Malicious code may use these classes to help in its attempt to compromise security in the system.
defineClassInPackage.{package name} Definition of classes in the specified package, via a class loader's defineClass method when that class loader calls the SecurityManager checkPackageDefinition method. This grants code permission to define a class in a particular package. This is dangerous because malicious code with this permission may define rogue classes in trusted packages like java.security or java.lang, for example.
accessDeclaredMembers Access to the declared members of a class This grants code permission to query a class for its public, protected, default (package) access, and private fields and/or methods. Although the code would have access to the private and protected field and method names, it would not have access to the private/protected field data and would not be able to invoke any private methods. Nevertheless, malicious code may use this information to better aim an attack. Additionally, it may invoke any public methods and/or access public fields in the class. This could be dangerous if the code would normally not be able to invoke those methods and/or access the fields because it can't cast the object to the class/interface with those methods and fields.
queuePrintJob Initiation of a print job request This could print sensitive information to a printer, or simply waste paper.
getStackTrace Retrieval of the stack trace information of another thread. This allows retrieval of the stack trace information of another thread. This might allow malicious code to monitor the execution of threads and discover vulnerabilities in applications.
setDefaultUncaughtExceptionHandler Setting the default handler to be used when a thread terminates abruptly due to an uncaught exception This allows an attacker to register a malicious uncaught exception handler that could interfere with termination of a thread
preferences Represents the permission required to get access to the java.util.prefs.Preferences implementations user or system root which in turn allows retrieval or update operations within the Preferences persistent backing store.) This permission allows the user to read from or write to the preferences backing store if the user running the code has sufficient OS privileges to read/write to that backing store. The actual backing store may reside within a traditional filesystem directory or within a registry depending on the platform OS

Creates a new RuntimePermission with the specified name. The name is the symbolic name of the RuntimePermission, such as "exit", "setFactory", etc. An asterisk may appear at the end of the name, following a ".", or by itself, to signify a wildcard match.
Parameters
namethe name of the RuntimePermission.
Creates a new RuntimePermission object with the specified name. The name is the symbolic name of the RuntimePermission, and the actions String is currently unused and should be null.
Parameters
namethe name of the RuntimePermission.
actionsshould be null.
Implements the guard interface for a permission. The SecurityManager.checkPermission method is called, passing this permission object as the permission to check. Returns silently if access is granted. Otherwise, throws a SecurityException.
Parameters
objectthe object being guarded (currently ignored).
Throws
SecurityException if a security manager exists and its checkPermission method doesn't allow access.
Checks two BasicPermission objects for equality. Checks that obj's class is the same as this object's class and has the same name as this object.

Parameters
objthe object we are testing for equality with this object.
Return
true if obj is a BasicPermission, and has the same name as this BasicPermission object, false otherwise.
Returns the canonical string representation of the actions, which currently is the empty string "", since there are no actions for a BasicPermission.
Return
the empty string "".
Returns the runtime class of an object. That Class object is the object that is locked by static synchronized methods of the represented class.
Return
The java.lang.Class object that represents the runtime class of the object. The result is of type {@code Class} where X is the erasure of the static type of the expression on which getClass is called.
Returns the name of this Permission. For example, in the case of a java.io.FilePermission, the name will be a pathname.
Return
the name of this Permission.
Returns the hash code value for this object. The hash code used is the hash code of the name, that is, getName().hashCode(), where getName is from the Permission superclass.
Return
a hash code value for this object.
Checks if the specified permission is "implied" by this object.

More specifically, this method returns true if:

  • p's class is the same as this object's class, and

  • p's name equals or (in the case of wildcards) is implied by this object's name. For example, "a.b.*" implies "a.b.c".
Parameters
pthe permission to check against.
Return
true if the passed permission is equal to or implied by this permission, false otherwise.
Returns a new PermissionCollection object for storing BasicPermission objects.

A BasicPermissionCollection stores a collection of BasicPermission permissions.

BasicPermission objects must be stored in a manner that allows them to be inserted in any order, but that also enables the PermissionCollection implies method to be implemented in an efficient (and consistent) manner.

Return
a new PermissionCollection object suitable for storing BasicPermissions.
Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the 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:

  • By executing a synchronized instance method of that object.
  • By executing the body of a synchronized statement that synchronizes on the object.
  • For objects of type Class, by executing a synchronized static method of that class.

Only one thread at a time can own an object's monitor.

Throws
IllegalMonitorStateExceptionif the current thread is not the owner of this object's monitor.
Wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the 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.

Throws
IllegalMonitorStateExceptionif the current thread is not the owner of this object's monitor.
Returns a string describing this Permission. The convention is to specify the class name, the permission name, and the actions in the following format: '("ClassName" "name" "actions")'.
Return
information about this Permission.
Causes current thread to wait until another thread invokes the method or the method for this object. In other words, this method behaves exactly as if it simply performs the call wait(0).

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.
Throws
IllegalMonitorStateExceptionif the current thread is not the owner of the object's monitor.
InterruptedExceptionif another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown.
Causes current thread to wait until either another thread invokes the method or the method for this object, or a specified amount of time has elapsed.

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:

  • Some other thread invokes the notify method for this object and thread T happens to be arbitrarily chosen as the thread to be awakened.
  • Some other thread invokes the notifyAll method for this object.
  • Some other thread interrupts thread T.
  • The specified amount of real time has elapsed, more or less. If timeout is zero, however, then real time is not taken into consideration and the thread simply waits until notified.
The thread T is then removed from the wait set for this object and re-enabled for thread scheduling. It then competes in the usual manner with other threads for the right to synchronize on the object; once it has gained control of the object, all its synchronization claims on the object are restored to the status quo ante - that is, to the situation as of the time that the wait method was invoked. Thread T then returns from the invocation of the wait method. Thus, on return from the wait method, the synchronization state of the object and of thread T is exactly as it was when the wait method was invoked.

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.

Parameters
timeoutthe maximum time to wait in milliseconds.
Throws
IllegalArgumentExceptionif the value of timeout is negative.
IllegalMonitorStateExceptionif the current thread is not the owner of the object's monitor.
InterruptedExceptionif another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown.
Causes current thread to wait until another thread invokes the method or the method for this object, or some other thread interrupts the current thread, or a certain amount of real time has elapsed.

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:

  • 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 timeout period, specified by 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.
Parameters
timeoutthe maximum time to wait in milliseconds.
nanosadditional time, in nanoseconds range 0-999999.
Throws
IllegalArgumentExceptionif the value of timeout is negative or the value of nanos is not in the range 0-999999.
IllegalMonitorStateExceptionif the current thread is not the owner of this object's monitor.
InterruptedExceptionif another thread interrupted the current thread before or while the current thread was waiting for a notification. The interrupted status of the current thread is cleared when this exception is thrown.