AWTPermission contains 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 AWT permission (see below). The naming convention follows the hierarchical property naming convention. Also, an asterisk could be used to represent all AWT permissions.
The following table lists all the possible AWTPermission
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 |
|---|---|---|
| accessClipboard | Posting and retrieval of information to and from the AWT clipboard | This would allow malfeasant code to share potentially sensitive or confidential information. |
| accessEventQueue | Access to the AWT event queue | After retrieving the AWT event queue, malicious code may peek at and even remove existing events from its event queue, as well as post bogus events which may purposefully cause the application or applet to misbehave in an insecure manner. |
| createRobot | Create java.awt.Robot objects | The java.awt.Robot object allows code to generate native-level mouse and keyboard events as well as read the screen. It could allow malicious code to control the system, run other programs, read the display, and deny mouse and keyboard access to the user. |
| fullScreenExclusive | Enter full-screen exclusive mode | Entering full-screen exclusive mode allows direct access to low-level graphics card memory. This could be used to spoof the system, since the program is in direct control of rendering. |
| listenToAllAWTEvents | Listen to all AWT events, system-wide | After adding an AWT event listener, malicious code may scan all AWT events dispatched in the system, allowing it to read all user input (such as passwords). Each AWT event listener is called from within the context of that event queue's EventDispatchThread, so if the accessEventQueue permission is also enabled, malicious code could modify the contents of AWT event queues system-wide, causing the application or applet to misbehave in an insecure manner. |
| readDisplayPixels | Readback of pixels from the display screen | Interfaces such as the java.awt.Composite interface or the java.awt.Robot class allow arbitrary code to examine pixels on the display enable malicious code to snoop on the activities of the user. |
| replaceKeyboardFocusManager | Sets the KeyboardFocusManager for
a particular thread.
| When SecurityManager is installed, the invoking
thread must be granted this permission in order to replace
the current KeyboardFocusManager. If permission
is not granted, a SecurityException will be thrown.
|
| showWindowWithoutWarningBanner | Display of a window without also displaying a banner warning that the window was created by an applet | Without this warning, an applet may pop up windows without the user knowing that they belong to an applet. Since users may make security-sensitive decisions based on whether or not the window belongs to an applet (entering a username and password into a dialog box, for example), disabling this warning banner may allow applets to trick the user into entering such information. |
| watchMousePointer | Getting the information about the mouse pointer position at any time | Constantly watching the mouse pointer, an applet can make guesses about what the user is doing, i.e. moving the mouse to the lower left corner of the screen most likely means that the user is about to launch an application. If a virtual keypad is used so that keyboard is emulated using the mouse, an applet may guess what is being typed. |
| setWindowAlwaysOnTop | Setting always-on-top property of the window: Window#setAlwaysOnTop | The malicious window might make itself look and behave like a real full desktop, so that information entered by the unsuspecting user is captured and subsequently misused |
| setAppletStub | Setting the stub which implements Applet container services | Malicious code could set an applet's stub and result in unexpected behavior or denial of service to an applet. |
AWTPermission with the specified name.
The name is the symbolic name of the AWTPermission,
such as "topLevelWindow", "systemClipboard", etc. An asterisk
may be used to indicate all AWT permissions.AWTPermission object with the specified name.
The name is the symbolic name of the AWTPermission, and the
actions string is currently unused and should be null.SecurityManager.checkPermission method is called,
passing this permission object as the permission to check.
Returns silently if access is granted. Otherwise, throws
a SecurityException.java.io.FilePermission,
the name will be a pathname.getName().hashCode(), where getName is
from the Permission superclass.More specifically, this method returns true if:
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.
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.
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.