A permission represents access to a system resource.
In order for a resource access to be allowed for an applet
(or an application running with a security manager),
the corresponding permission must be explicitly granted to
the code attempting the access.
A permission typically has a name (often referred to as a
"target name") and, in some cases, a comma-separated list of
one or more actions. For example, the following code
creates a FilePermission object representing read access to
the file named abc in the /tmp directory:
perm = new java.io.FilePermission("/tmp/abc", "read");
In this, the target name is "/tmp/abc" and the action string
is "read".
Important: The above statement creates a permission object.
A permission object represents, but does not grant
access to, a system resource.
Permission objects are constructed and assigned ("granted") to code
based on the policy in effect.
When a permission object is assigned to some code, that
code is granted the permission to access the system resource
specified in the permission object, in the specified manner.
A permission object may also be constructed by the current
security manager
when making access decisions. In this case, the (target) permission
object is created based on the requested access, and checked against the
permission objects granted to and held by the code making the request.
The policy for a Java application environment
is represented by a Policy object.
In the default Policy implementation, the policy
can be specified within one
or more policy configuration files.
The policy file(s) specify what
permissions are allowed for code from specified code sources.
A sample policy file entry granting code from
the /home/sysadmin directory
read access to the file /tmp/abc is
grant codeBase "file:/home/sysadmin/" {
permission java.io.FilePermission "/tmp/abc", "read";
};
For information about policy file locations and
granting permissions in policy files, see
Default Policy Implementation and Policy File Syntax.
For information about using the Policy Tool to specify the
permissions, see the Policy Tool documentation
(for Solaris)
(for Windows).
Using the Policy Tool saves typing and eliminates the need
for you to know the required syntax of policy files.
Technically, whenever a resource access is attempted, all code
traversed by the execution thread up to that point must have permission
for that resource access, unless some code on the thread has been marked
as "privileged." See
API for Privileged Blocks for more
information about "privileged" code.
This document contains tables that describe the built-in
Java 2 SDK permission types and discuss the risks of granting each
permission. It also contains tables showing the methods that
require permissions to be in effect in order to be successful,
and for each lists the required permission.
For more information about permissions, including the superclasses
java.security.Permission and
java.security.BasicPermission, and examples
of creating permission objects and granting permissions, see the
Security Architecture Specification.
The java.security.AllPermission is a permission that implies all
other permissions.
Note: Granting AllPermission should be done
with extreme care,
as it implies all other permissions. Thus, it grants code the ability
to run with security
disabled. Extreme caution should be taken before granting such
a permission to code. This permission should be used only during testing,
or in extremely rare cases where an application or applet is
completely trusted and adding the necessary permissions to the policy
is prohibitively cumbersome.
The AudioPermission class represents access rights to the audio
system resources. An AudioPermission 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 audio permission (see the table below).
The names follow the hierarchical property-naming convention. Also, an asterisk
can be used to represent all the audio permissions.
The following table lists the possible AudioPermission target name
s.
For each name, the table provides a description of exactly what that permission
allows, as well as a discussion of the risks of granting code the permission.
Permission Target Name
What the Permission Allows
Risks of Allowing this Permission
play
Audio playback through the audio device or devices on the system.
Allows the application to obtain and manipulate lines and mixers for
audio playback (rendering).
In some cases use of this permission may affect other
applications because the audio from one line may be mixed with other audio
being played on the system, or because manipulation of a mixer affects the
audio for all lines using that mixer.
record
Audio recording through the audio device or devices on the system.
Allows the application to obtain and manipulate lines and mixers for
audio recording (capture).
In some cases use of this permission may affect other
applications because manipulation of a mixer affects the audio for all lines
using that mixer.
This permission can enable an applet or application to eavesdrop on a user.
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.
java.awt.AWTPermission 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 the system, 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.
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 which
allow arbitrary code to examine pixels on the display enable
malicious code to snoop on the activities of the user.
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.
A java.io.FilePermission represents access to a file or directory. A FilePermission consists
of a pathname and a set of actions valid for that pathname.
Pathname is the pathname of the file or directory granted the specified
actions. A pathname that ends in "/*" (where "/" is
the file separator character, File.separatorChar) indicates
a directory and all the files contained in that directory. A pathname
that ends with "/-" indicates a directory and (recursively) all files
and subdirectories contained in that directory. A pathname consisting of
the special token "<<ALL FILES>>" matches any file.
A pathname consisting of a single "*" indicates all the files
in the current directory, while a pathname consisting of a single "-"
indicates all the files in the current directory and
(recursively) all files and subdirectories contained in the current
directory.
The actions to be granted are passed to the constructor in a string containing
a list of zero or more comma-separated keywords. The possible keywords are
"read", "write", "execute", and "delete". Their meaning is defined as follows:
read
Permission to read.
write
Permission to write (which includes permission to create).
execute
Permission to execute. Allows Runtime.exec to
be called. Corresponds to SecurityManager.checkExec.
delete
Permission to delete. Allows File.delete to
be called. Corresponds to SecurityManager.checkDelete.
The actions string is converted to lowercase before processing.
Be careful when granting FilePermissions.
Think about the implications
of granting read and especially write access to various files and
directories. The "<<ALL FILES>>" permission with write action is
especially dangerous. This grants permission to write to the entire
file system. One thing this effectively allows is replacement of the
system binary, including the JVM runtime environment.
Please note: code can always read a file from the same
directory it's in (or a subdirectory of that directory); it does not
need explicit permission to do so.
A java.net.NetPermission is for various network permissions.
A NetPermission contains a name but
no actions list; you either have the named permission
or you don't.
The following table lists all the possible NetPermission target names,
and for each provides a description of what the permission allows
and a discussion of the risks of granting code the permission.
java.net.NetPermission Target Name
What the Permission Allows
Risks of Allowing this Permission
setDefaultAuthenticator
The ability to set the
way authentication information is retrieved when
a proxy or HTTP server asks for authentication
Malicious
code can set an authenticator that monitors and steals user
authentication input as it retrieves the input from the user.
requestPasswordAuthentication
The ability
to ask the authenticator registered with the system for
a password
Malicious code may steal this password.
specifyStreamHandler
The ability
to specify a stream handler when constructing a URL
Malicious code may create a URL with resources that it would
normally not have access to (like file:/foo/fum/), specifying a
stream handler that gets the actual bytes from someplace it does
have access to. Thus it might be able to trick the system into
creating a ProtectionDomain/CodeSource for a class even though
that class really didn't come from that location.
A java.util.PropertyPermission is for property permissions.
The name is the name of the property ("java.home",
"os.name", etc). 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: "java.*" or "*" is valid,
"*java" or "a*b" is not valid.
The actions to be granted are passed to the constructor in a string containing
a list of zero or more comma-separated keywords. The possible keywords are
"read" and "write". Their meaning is defined as follows:
read
Permission to read. Allows System.getProperty to
be called.
write
Permission to write. Allows System.setProperty to
be called.
The actions string is converted to lowercase before processing.
Care should be taken before granting code permission to access
certain system properties. For example, granting permission to
access the "java.home" system property gives potentially malevolent
code sensitive information about the system environment (the location
of the runtime environment's directory). Also, granting permission to access
the "user.name" and "user.home" system properties gives potentially
malevolent code sensitive information about the user environment
(the user's account name and home directory).
A java.lang.reflect.ReflectPermission is for reflective
operations. A
ReflectPermission is a named permission and has no
actions. The only name currently defined is suppressAccessChecks,
which allows suppressing the standard language access checks
-- for public, default (package) access, protected, and private
members -- performed by reflected objects at their point of use.
The following table
provides a summary description of what the permission allows,
and discusses the risks of granting code the permission.
java.lang.reflect.ReflectPermission Target Name
What the Permission Allows
Risks of Allowing this Permission
suppressAccessChecks
The ability to access
fields and invoke methods in a class. Note that this includes
not only public, but protected and private fields and methods as well.
This is dangerous in that information (possibly confidential) and
methods normally unavailable would be accessible to malicious code.
A java.lang.RuntimePermission 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.
java.lang.RuntimePermission 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.
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.
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.
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" OutputSteam,
which would hide any error messages sent to System.err.
modifyThread
stop,
suspend, resume, setPriority,
and setName methods
This allows an attacker to start or suspend 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, 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 malicous
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 checkPackageAcesss 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.
A java.security.SecurityPermission is for security permissions.
A SecurityPermission 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 a security configuration parameter (see below).
Currently the SecurityPermission object is used to guard access
to the Policy, Security, Provider, Signer, and Identity
objects.
The following table lists all the possible SecurityPermission
target names,
and for each provides a description of what the permission allows
and a discussion of the risks of granting code the permission.
java.security.SecurityPermission Target Name
What the Permission Allows
Risks of Allowing this Permission
createAccessControlContext
Creation of an AccessControlContext
This allows someone to instantiate an AccessControlContext with a
DomainCombiner. Since DomainCombiners are given a reference to the
ProtectionDomains currently on the stack, this could potentially
lead to a privacy leak if the DomainCombiner is malicious.
getDomainCombiner
Retrieval of an AccessControlContext's DomainCombiner
This allows someone to query the policy via the getPermissions call,
which discloses which permissions would be granted to a given
CodeSource. While revealing the policy does not compromise the
security of the system, it does provide malicious code with additional
information which it may use to better aim an attack. It is wise not
to divulge more information than necessary.
getPolicy
Retrieval of the system-wide security policy (specifically, of the
currently-installed Policy object)
This allows someone to query the policy via the
getPermissions call,
which discloses which permissions would be granted to a given CodeSource.
While revealing the policy does not compromise the security of
the system, it does provide malicious code with additional information
which it may use to better aim an attack. It is wise
not to divulge more information than necessary.
setPolicy
Setting of the system-wide security policy (specifically,
the Policy object)
Granting this permission is extremely dangerous, as malicious
code may grant itself all the necessary permissions it needs
to successfully mount an attack on the system.
getProperty.{key}
Retrieval of the security property with the specified key
Depending on the particular key for which access has
been granted, the code may have access to the list of security
providers, as well as the location of the system-wide and user
security policies. while revealing this information does not
compromise the security of the system, it does provide malicious
code with additional information which it may use to better aim
an attack.
setProperty.{key}
Setting of the security property with the specified key
This could include setting a security provider or defining
the location of the the system-wide security policy. Malicious
code that has permission to set a new security provider may
set a rogue provider that steals confidential information such
as cryptographic private keys. In addition, malicious code with
permission to set the location of the system-wide security policy
may point it to a security policy that grants the attacker
all the necessary permissions it requires to successfully mount
an attack on the system.
insertProvider.{provider name}
Addition of a new provider, with the specified name
This would allow somebody to introduce a possibly
malicious provider (e.g., one that discloses the private keys passed
to it) as the highest-priority provider. This would be possible
because the Security object (which manages the installed providers)
currently does not check the integrity or authenticity of a provider
before attaching it.
removeProvider.{provider name}
Removal of the specified provider
This may change the behavior or disable execution of other
parts of the program. If a provider subsequently requested by the
program has been removed, execution may fail. Also, if the removed
provider is not explicitly requested by the rest of the program, but
it would normally be the provider chosen when a cryptography service
is requested (due to its previous order in the list of providers),
a different provider will be chosen instead, or no suitable provider
will be found, thereby resulting in program failure.
setSystemScope
Setting of the system identity scope
This would allow an attacker to configure the system identity scope with
certificates that should not be trusted, thereby granting applet or
application code signed with those certificates privileges that
would have been denied by the system's original identity scope
setIdentityPublicKey
Setting of the public key for an Identity
If the identity is marked as "trusted", this allows an attacker to
introduce a different public key (e.g., its own) that is not trusted
by the system's identity scope, thereby granting applet or
application code signed with that public key privileges that
would have been denied otherwise.
setIdentityInfo
Setting of a general information string for an Identity
This allows attackers to set the general description for
an identity. This may trick applications into using a different
identity than intended or may prevent applications from finding a
particular identity.
addIdentityCertificate
Addition of a certificate for an Identity
This allows attackers to set a certificate for
an identity's public key. This is dangerous because it affects
the trust relationship across the system. This public key suddenly
becomes trusted to a wider audience than it otherwise would be.
removeIdentityCertificate
Removal of a certificate for an Identity
This allows attackers to remove a certificate for
an identity's public key. This is dangerous because it affects
the trust relationship across the system. This public key suddenly
becomes considered less trustworthy than it otherwise would be.
printIdentity
Viewing the name of a principal
and optionally the scope in which it is used, and whether
or not it is considered "trusted" in that scope.
The scope that is printed out may be a filename, in which case
it may convey local system information. For example, here's a sample
printout of an identity named "carol", who is
marked not trusted in the user's identity database:
carol[/home/luehe/identitydb.obj][not trusted]
clearProviderProperties.{provider name}
"Clearing" of a Provider so that it no longer contains the properties
used to look up services implemented by the provider
This disables the lookup of services implemented by the provider.
This may thus change the behavior or disable execution of other
parts of the program that would normally utilize the Provider, as
described under the "removeProvider.{provider name}" permission.
putProviderProperty.{provider name}
Setting of properties for the specified Provider
The provider properties each specify the name and location
of a particular service implemented by the provider. By granting
this permission, you let code replace the service specification
with another one, thereby specifying a different implementation.
removeProviderProperty.{provider name}
Removal of properties from the specified Provider
This disables the lookup of services implemented by the
provider. They are no longer accessible due to removal of the properties
specifying their names and locations. This
may change the behavior or disable execution of other
parts of the program that would normally utilize the Provider, as
described under the "removeProvider.{provider name}" permission.
getSignerPrivateKey
Retrieval of a Signer's private key
It is very dangerous to allow access to a private key; private
keys are supposed to be kept secret. Otherwise, code can use the
private key to sign various files and claim the signature came from
the Signer.
setSignerKeyPair
Setting of the key pair (public key and private key) for a Signer
This would allow an attacker to replace somebody else's (the "target's")
keypair with a possibly weaker keypair (e.g., a keypair of a smaller
keysize). This also would allow the attacker to listen in on encrypted
communication between the target and its peers. The target's peers
might wrap an encryption session key under the target's "new" public
key, which would allow the attacker (who possesses the corresponding
private key) to unwrap the session key and decipher the communication
data encrypted under that session key.
A java.io.SerializablePermission is for serializable permissions.
A SerializablePermission
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 Serializable permission (see below).
The following table lists all the possible SerializablePermission
target names,
and for each provides a description of what the permission allows
and a discussion of the risks of granting code the permission.
java.io.SerializablePermission Target Name
What the Permission Allows
Risks of Allowing this Permission
enableSubclassImplementation
Implementing a subclass of ObjectOutputStream or ObjectInputStream
to override the default serialization or deserialization, respectively,
of objects
Code can use this to serialize or
deserialize classes in a purposefully malfeasant manner. For example,
during serialization, malicious code can use this to
purposefully store confidential private field data in a way easily accessible
to attackers. Or, during deserializaiton it could, for example, deserialize
a class with all its private fields zeroed out.
enableSubstitution
Substitution of one object for another during
serialization or deserialization
This is dangerous because malicious code
can replace the actual object with one which has incorrect or
malignant data.
A java.net.SocketPermission represents access to a
network via sockets.
A SocketPermission consists of a
host specification and a set of "actions" specifying ways to
connect to that host. The host is specified as
The host is expressed as a DNS name, as a numerical IP address,
or as "localhost" (for the local machine).
The wildcard "*" may be included once in a DNS name host
specification. If it is included, it must be in the leftmost
position, as in "*.sun.com".
The port or portrange is optional. A port specification of the
form "N-", where N is a port number, signifies all ports
numbered N and above, while a specification of the
form "-N" indicates all ports numbered N and below.
The possible ways to connect to the host are
accept
connect
listen
resolve
The "listen" action is only meaningful when used with "localhost".
The "resolve" (resolve host/ip name service lookups) action is implied
when any of the other actions are present.
As an example of the creation and meaning of SocketPermissions,
note that if you have the following entry in your policy file:
grant signedBy "mrm" {
permission java.net.SocketPermission "puffin.eng.sun.com:7777", "connect,
accept";
};
this causes the following permission object to be generated
and granted to code signed by "mrm."
p1 = new SocketPermission("puffin.eng.sun.com:7777", "connect,accept");
p1 represents a permission allowing connections to port 7777 on
puffin.eng.sun.com, and also accepting connections on that
port.
Similarly, if you have the following entry in your policy:
this causes the following permission object to be generated
and granted to code signed by "paul."
p2 = new SocketPermission("localhost:1024-", "accept,connect,listen");
p2 represents a permission allowing accepting connections on,
connecting to, or listening on any port between 1024 and
65535 on the local host.
Note: Granting code permission to accept or make connections to remote
hosts may be dangerous because malevolent code can then more easily
transfer and share confidential data among parties who may not
otherwise have access to the data.
The permission for which the SecurityManager will check
when code that is running in an applet calls one of the
setLogWriter methods. These methods include those in the
following list.
DriverManager.setLogWriter
DriverManager.setLogStream (deprecated)
javax.sql.DataSource.setLogWriter
javax.sql.ConnectionPoolDataSource.setLogWriter
javax.sql.XADataSource.setLogWriter
If there is no SQLPermission object, this method
throws a java.lang.SecurityException as a runtime exception.
A SQLPermission object contains
a name (also referred to as a "target name") but no actions
list; there is either a named permission or there is not.
The target name is the name of the permission (see below). The
naming convention follows the hierarchical property naming convention.
In addition, 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,
but *loadLibrary or a*b is not valid.
The following table lists all the possible SQLPermission target na
mes.
Currently, the only name allowed is setLog.
The table gives 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
setLog
Setting of the logging stream
This is a dangerous permission to grant.
The contents of the log may contain usernames and passwords,
SQL statements, and SQL data.
The person running an applet decides what permissions to allow
and will run the Policy Tool to create an
SQLPermission in a policy file. A programmer does
not use a constructor directly to create an instance of
SQLPermission but rather uses a tool.
The following table contains a list of all the Java 2 SDK methods
that require permissions, and for each tells which SecurityManager
method it calls and which permission is checked for by the default
implementation of that SecurityManager method.
Thus, with the default SecurityManager method implementations,
a call to a method in the left-hand column can only be successful
if the permission specified in the corresponding entry in the
right-hand column is allowed by the policy
currently in effect. For example, the following row:
Method
SecurityManager Method Called
Permission
java.awt.Toolkit
getSystemEventQueue();
checkAwtEventQueueAccess
java.awt.AWTPermission "accessEventQueue";
specifies that a call to the getSystemEventQueue method
in the java.awt.Toolkit class results in a call to the
checkAwtEventQueueAccess SecurityManager method,
which can only be successful if the following
permission is granted to code on the call stack:
java.awt.AWTPermission "accessEventQueue";
The convention of:
Method
SecurityManager Method Called
Permission
some.package.class
public static void someMethod(String foo);
checkXXX
SomePermission "{foo}";
means the runtime value of foo replaces the string {foo}
in the permission name.
If the FileInputStream method (in this case, a constructor) is
called with "/test/MyTestFile" as the name argument, as in
FileInputStream("/test/MyTestFile");
then in order for the call to succeed, the following permission must
be set in the current policy, allowing read access to the file "/test/MyTestFile":
More specifically, the permission must either be explicitly set,
as above, or implied by another permission, such as the following:
java.io.FilePermission "/test/*", "read";
which allows read access to any files in the "/test" directory.
In some cases, a term in braces is not
exactly the same as the name of a specific method argument but is meant to represent
the relevant value. Here is an example:
Method
SecurityManager Method Called
Permission
java.net.DatagramSocket
public synchronized void
receive(DatagramPacket p);
Here, the appropriate host and port values are calculated by the
receive method and passed to checkAccept.
In most cases, just the name of the SecurityManager method called
is listed. Where the method is one of multiple methods of the same
name, the argument types are also listed, for example for
checkRead(String) and
checkRead(FileDescriptor). In other cases where
arguments may be relevant, they are also listed.
The following table is ordered by package name. That is, the methods
in classes in the java.awt package are listed first,
followed by methods in classes in the java.io package,
and so on.
Methods and the Permissions They Require
Method
SecurityManager Method Called
Permission
java.awt.Graphics2d
public abstract void
setComposite(Composite comp)
checkPermission
java.awt.AWTPermission "readDisplayPixels"
if this Graphics2D context is drawing to a
Component on the display screen and the
Composite is a custom object rather than an
instance of the AlphaComposite class.
Note: The setComposite method is actually
abstract and thus can't invoke security checks.
Each actual implementation of the method should call
the java.lang.SecurityManager checkPermission method
with a
java.awt.AWTPermission("readDisplayPixels") permission
under the conditions noted.
java.awt.Robot
public Robot()
public Robot(GraphicsDevice screen)
checkPermission
java.awt.AWTPermission "createRobot"
java.awt.Toolkit
public void addAWTEventListener(
AWTEventListener listener,
long eventMask)
public void removeAWTEventListener(
AWTEventListener listener)
Note: The getPrintJob method is actually
abstract and thus can't invoke security checks.
Each actual implementation of the method should call
the java.lang.SecurityManager checkPrintJobAccess method,
which is successful only if the
java.lang.RuntimePermission "queuePrintJob"
permission is currently allowed.
java.awt.Toolkit
public abstract Clipboard
getSystemClipboard()
checkSystemClipboardAccess
java.awt.AWTPermission "accessClipboard"
Note: The getSystemClipboard method is actually
abstract and thus can't invoke security checks.
Each actual implementation of the method should call
the java.lang.SecurityManager checkSystemClipboardAccess
method, which is successful only if the
java.awt.AWTPermission "accessClipboard"
permission is currently allowed.
java.awt.Toolkit
public final EventQueue
getSystemEventQueue()
checkAwtEventQueueAccess
java.awt.AWTPermission "accessEventQueue"
java.awt.Window
Window()
checkTopLevelWindow
If java.awt.AWTPermission "showWindowWithoutWarningBanner"
is set, the window will be displayed without a banner warning that
the window was created by an applet. It it's not set, such a banner
will be displayed.
java.beans.Beans
public static void setDesignTime(
boolean isDesignTime)
public static void setGuiAvailable(
boolean isGuiAvailable)
java.beans.Introspector
public static synchronized void
setBeanInfoSearchPath(String path[])
java.beans.PropertyEditorManager
public static void registerEditor(
Class targetType,
Class editorClass)
public static synchronized void
setEditorSearchPath(String path[])
checkPropertiesAccess
java.util.PropertyPermission "*", "read,write"
java.io.File
public boolean delete()
public void deleteOnExit()
java.io.FileInputStream
FileInputStream(String name)
FileInputStream(File file)
java.io.File
public boolean exists()
public boolean canRead()
public boolean isFile()
public boolean isDirectory()
public boolean isHidden()
public long lastModified()
public long length()
public String[] list()
public String[] list(
FilenameFilter filter)
public File[] listFiles()
public File[] listFiles(
FilenameFilter filter)
public File[] listFiles(
FileFilter filter)
java.io.RandomAccessFile
RandomAccessFile(String name, String mode)
RandomAccessFile(File file, String mode)
(where mode is "r" in both of these)
java.io.RandomAccessFile
RandomAccessFile(String name, String mode)
(where mode is "rw")
checkRead(String) and checkWrite(String)
java.io.FilePermission "{name}", "read,write"
java.lang.Class
public static Class forName(
String name, boolean initialize,
ClassLoader loader)
checkPermission
If loader is null, and
the caller's class loader is not null, then
java.lang.RuntimePermission("getClassLoader")
java.lang.Class
public Class[] getClasses()
For this class and each of its superclasses,
checkMemberAccess(this, Member.DECLARED) is called
and, if the class is in a package, checkPackageAccess({pkgName}) is called.
Default checkMemberAccess does not require any permissions if
"this" class's classloader is the same as that of the caller.
Otherwise, it
requires java.lang.RuntimePermission "accessDeclaredMembers".
If the class is in a package,
java.lang.RuntimePermission "accessClassInPackage.{pkgName}"
is also required.
java.lang.Class
public ClassLoader getClassLoader()
checkPermission
If the caller's class loader is null, or is the same as or an ancestor of
the class loader for the class whose class loader is being requested, no
permission is needed. Otherwise,
java.lang.RuntimePermission "getClassLoader"
is required.
java.lang.Class
public Class[] getDeclaredClasses()
public Field[] getDeclaredFields()
public Method[] getDeclaredMethods()
public Constructor[]
getDeclaredConstructors()
public Field getDeclaredField(
String name)
public Method getDeclaredMethod(...)
public Constructor
getDeclaredConstructor(...)
checkMemberAccess(this, Member.DECLARED)
and, if this class is in a package, checkPackageAccess({pkgName})
Default checkMemberAccess does not require any permissions if
"this" class's classloader is the same as that of the caller. Otherwise, it
requires java.lang.RuntimePermission "accessDeclaredMembers".
If this class is in a package,
java.lang.RuntimePermission "accessClassInPackage.{pkgName}"
is also required.
java.lang.Class
public Field[] getFields()
public Method[] getMethods()
public Constructor[] getConstructors()
public Field getField(String name)
public Method getMethod(...)
public Constructor getConstructor(...)
checkMemberAccess(this, Member.PUBLIC)
and, if class is in a package, checkPackageAccess({pkgName})
Default checkMemberAccess does not require any permissions when
the access type is Member.PUBLIC. If this class is in a package,
java.lang.RuntimePermission "accessClassInPackage.{pkgName}"
is required.
java.lang.Class
public ProtectionDomain
getProtectionDomain()
java.lang.ClassLoader
public static ClassLoader
getSystemClassLoader()
public ClassLoader getParent()
checkPermission
If the caller's class loader is null, or is the same as or an ancestor of
the class loader for the class whose class loader is being requested, no
permission is needed. Otherwise,
java.lang.RuntimePermission "getClassLoader"
is required.
java.lang.Runtime
public Process exec(String command)
public Process exec(String command,
String envp[])
public Process exec(String cmdarray[])
public Process exec(String cmdarray[],
String envp[])
checkExec
java.io.FilePermission "{command}", "execute"
java.lang.Runtime
public void exit(int status)
public static void
runFinalizersOnExit(boolean value)
java.lang.System
public static void exit(int status)
public static void
runFinalizersOnExit(boolean value)
checkExit(status) where status is 0 for runFinalizersOnExit
java.lang.RuntimePermission "exitVM"
java.lang.Runtime
public void addShutdownHook(Thread hook)
public boolean removeShutdownHook(Thread hook)
checkPermission
java.lang.RuntimePermission "shutdownHooks"
java.lang.Runtime
public void load(String lib)
public void loadLibrary(String lib)
java.lang.System
public static void load(String filename)
public static void loadLibrary(
String libname)
checkLink({libName}) where {libName} is the
lib, filename or libname argument
java.lang.System
public static Properties
getProperties()
public static void
setProperties(Properties props)
checkPropertiesAccess
java.util.PropertyPermission "*", "read,write"
java.lang.System
public static String
getProperty(String key)
public static String
getProperty(String key, String def)
checkPropertyAccess
java.util.PropertyPermission "{key}", "read"
java.lang.System
public static void setIn(InputStream in)
public static void setOut(PrintStream out)
public static void setErr(PrintStream err)
checkPermission
java.lang.RuntimePermission "setIO"
java.lang.System
public static String
setProperty(String key, String value)
checkPermission
java.util.PropertyPermission "{key}", "write"
java.lang.System
public static synchronized void
setSecurityManager(SecurityManager s)
checkPermission
java.lang.RuntimePermission "setSecurityManager"
java.lang.Thread
public ClassLoader getContextClassLoader()
checkPermission
If the caller's class loader is null, or is the same as or an ancestor of
the context class loader for the thread whose context class loader is being
requested, no permission is needed. Otherwise,
java.lang.RuntimePermission "getClassLoader"
is required.
java.lang.Thread
public void setContextClassLoader
(ClassLoader cl)
java.lang.Thread
public final void checkAccess()
public void interrupt()
public final void suspend()
public final void resume()
public final void setPriority
(int newPriority)
public final void setName(String name)
public final void setDaemon(boolean on)
checkAccess(this)
java.lang.RuntimePermission "modifyThread"
java.lang.Thread
public static int
enumerate(Thread tarray[])
checkAccess({threadGroup})
java.lang.RuntimePermission "modifyThreadGroup"
java.lang.Thread
public final void stop()
checkAccess(this). Also checkPermission if
the current thread is trying to stop a thread other than itself.
java.lang.RuntimePermission "modifyThread".
Also java.lang.RuntimePermission "stopThread" if
the current thread is trying to stop a thread other than itself.
java.lang.Thread
public final synchronized void
stop(Throwable obj)
checkAccess(this). Also checkPermission if
the current thread is trying to stop a thread other than itself
or obj is not an instance of ThreadDeath.
java.lang.RuntimePermission "modifyThread".
Also java.lang.RuntimePermission "stopThread" if
the current thread is trying to stop a thread other than itself
or obj is not an instance of ThreadDeath.
java.lang.Thread
Thread(ThreadGroup group, ...)
java.lang.ThreadGroup
public final void checkAccess()
public int enumerate(Thread list[])
public int enumerate(Thread list[],
boolean recurse)
public int enumerate(ThreadGroup list[])
public int enumerate(ThreadGroup list[],
boolean recurse)
public final ThreadGroup getParent()
public final void
setDaemon(boolean daemon)
public final void setMaxPriority(int pri)
public final void suspend()
public final void resume()
public final void destroy()
checkAccess(this) for ThreadGroup methods, or
checkAccess(group) for Thread methods
java.lang.RuntimePermission "modifyThreadGroup"
java.lang.ThreadGroup
public final void interrupt()
checkAccess(this)
Requires java.lang.RuntimePermission "modifyThreadGroup".
Also requires
java.lang.RuntimePermission "modifyThread", since
the java.lang.Thread interrupt() method
is called for each thread in the thread group and in all of its subgroups.
See the Thread interrupt() method.
java.lang.ThreadGroup
public final void stop()
checkAccess(this)
Requires java.lang.RuntimePermission "modifyThreadGroup".
Also requires
java.lang.RuntimePermission "modifyThread" and possibly
java.lang.RuntimePermission "stopThread", since the java.lang.Thread stop() method
is called for each thread in the thread group and in all of its subgroups.
See the Thread stop() method.
java.lang.reflect.AccessibleObject
public static void setAccessible(...)
public void setAccessible(...)
java.net.DatagramSocket
public void send(DatagramPacket p)
checkMulticast(p.getAddress()) or
checkConnect(
p.getAddress().getHostAddress(), p.getPort())
if (p.getAddress().isMulticastAddress()) {
java.net.SocketPermission(
(p.getAddress()).getHostAddress(), "accept,connect")
}
else {
port = p.getPort();
host = p.getAddress().getHostAddress();
if (port == -1) java.net.SocketPermission "{host}","resolve";
else java.net.SocketPermission "{host}:{port}","connect"
}
java.net.MulticastSocket
public synchronized void
send(DatagramPacket p, byte ttl)
checkMulticast(p.getAddress(), ttl) or
checkConnect(
p.getAddress().getHostAddress(), p.getPort())
if (p.getAddress().isMulticastAddress()) {
java.net.SocketPermission(
(p.getAddress()).getHostAddress(), "accept,connect")
}
else {
port = p.getPort();
host = p.getAddress().getHostAddress();
if (port == -1) java.net.SocketPermission "{host}","resolve";
else java.net.SocketPermission "{host}:{port}","connect"
}
java.net.InetAddress
public String getHostName()
public static InetAddress[]
getAllByName(String host)
public static InetAddress getLocalHost()
java.net.DatagramSocket
public InetAddress getLocalAddress()
java.security.AccessControlContext
public AccessControlContext(AccessControlContext acc,
DomainCombiner combiner)
public DomainCombiner getDomainCombiner()
This table shows which permissions are checked for by the
default implementations of the
java.lang.SecurityManager methods.
Each of the specified check methods calls the
SecurityManagercheckPermission method with the specified permission,
except for the checkConnect and checkRead
methods that take a context argument.
Those methods expect the context to be an AccessControlContext
and they call the context's checkPermission method
with the specified permission.
if (port == -1) java.net.SocketPermission "{host}","resolve";
else java.net.SocketPermission "{host}:{port}","connect";
public void checkConnect(String host, int port, Object context);
if (port == -1) java.net.SocketPermission "{host}","resolve";
else java.net.SocketPermission "{host}:{port}","connect";
public void checkCreateClassLoader();
java.lang.RuntimePermission "createClassLoader";
public void checkDelete(String file);
java.io.FilePermission "{file}", "delete";
public void checkExec(String cmd);
if cmd is an absolute path: java.io.FilePermission "{cmd}", "execute";
else java.io.FilePermission "-", "execute";
public void checkExit(int status);
java.lang.RuntimePermission "exitVM");
public void checkLink(String lib);
java.lang.RuntimePermission "loadLibrary.{lib}";
public void checkListen(int port);
if (port == 0)
java.net.SocketPermission "localhost:1024-","listen";
else
java.net.SocketPermission "localhost:{port}","listen";
public void checkMemberAccess(Class clazz, int which);
if (which != Member.PUBLIC) {
if (currentClassLoader() != clazz.getClassLoader()) {
checkPermission(
new java.lang.RuntimePermission("accessDeclaredMembers"));
}
}