Permissions in the Java Development Kit (JDK)

A permission represents access to a system resource. In orderfor a resource access to be allowed for an applet (or anapplication running with a security manager), the correspondingpermission must be explicitly granted to the code attempting theaccess.

A permission typically has a name (often referred to as a"target name") and, in some cases, a comma-separated list of one ormore actions. For example, the following code creates aFilePermission object representing read access to the file namedabc in the/tmp directory:

perm = new java.io.FilePermission("/tmp/abc", "read");

In this, the target name is "/tmp/abc" and theaction string is "read".

Important Note: The above statement creates a permissionobject. A permission object represents, but does not grant accessto, a system resource. Permission objects are constructed andassigned ("granted") to code based on the policy in effect. When apermission object is assigned to some code, that code is grantedthe permission to access the system resource specified in thepermission object, in the specified manner. A permission object mayalso be constructed by the current security manager when makingaccess decisions. In this case, the (target) permission object iscreated based on the requested access, and checked against thepermission objects granted to and held by the code making therequest.

The policy for a Java application environment is represented bya Policy object. In the"JavaPolicy" Policyimplementation, the policy can be specified within one or morepolicy configuration files. The policy file(s) specify whatpermissions are allowed for code from specified code sources. Asample policy file entry that grants 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 grantingpermissions in policy files, seeDefaultPolicy Implementation and Policy File Syntax. For informationabout using thePolicy Tool to specify the permissions, seethe Policy Tool documentation (for Solaris) (for Windows). Using thePolicy Tool saves typing and eliminates the need for you toknow the required syntax of policy files.

Technically, whenever a resource access is attempted,allcode traversed by the execution thread up to that point must havepermission for that resource access, unless some code on the threadhas been marked as "privileged." SeeAPI for Privileged Blocks for moreinformation about "privileged" code.

This document contains tables that describe the built-in JDKpermission types and discuss the risks of granting each permission.It also contains tables showing the methods that requirepermissions to be in effect in order to be successful, and for eachlists the required permission.

The following topics are covered:

For more information about permissions, including thesuperclassesjava.security.Permission andjava.security.BasicPermission, and examples ofcreating permission objects and granting permissions, see theSecurity ArchitectureSpecification.

Permission Descriptionsand Risks

The following tables describe the built-in JDK permission typesand discuss the risks of granting each permission.

`AllPermission`

Thejava.security.AllPermissionis a permission that implies all other permissions.

Note: GrantingAllPermission should be donewith extreme care, as it implies all other permissions. Thus, itgrants code the ability to run with security disabled. Extremecaution should be taken before granting such a permission to code.This permission should be used only during testing, or in extremelyrare cases where an application or applet is completely trusted andadding the necessary permissions to the policy is prohibitivelycumbersome.

`SecurityPermission`

Ajava.security.SecurityPermissionis for security permissions. ASecurityPermissioncontains a name (also referred to as a "target name") but noactions list; you either have the named permission or youdon't.

The target name is the name of a security configurationparameter (see below). Currently theSecurityPermission object is used to guard access tothePolicy,Security,Provider,Signer, andIdentity objects.

The following table lists all the possibleSecurityPermission target names, and for each providesa description of what the permission allows and a discussion of therisks 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`. Extreme care must be taken whengranting this permission. Malicious code could create a`DomainCombiner` that augments the set of permissionsgranted to code, and even grant the code`AllPermission`.
`getDomainCombiner`	Retrieval of an`AccessControlContext`'s`DomainCombiner`	This allows someone to query the policy via the getPermissionscall, which discloses which permissions would be granted to a givenCodeSource. While revealing the policy does not compromise thesecurity of the system, it does provide malicious code withadditional information which it may use to better aim an attack. Itis wise not to divulge more information than necessary.
`getPolicy`	Retrieval of the system-wide security policy (specifically, ofthe currently-installed Policy object)	This allows someone to query the policy via the`getPermissions` call, which discloses which permissionswould be granted to a given`CodeSource`. Whilerevealing the policy does not compromise the security of thesystem, it does provide malicious code with additional informationwhich it may use to better aim an attack. It is wise not to divulgemore information than necessary.
`setPolicy`	Setting of the system-wide security policy (specifically, thePolicy object)	Granting this permission is extremely dangerous, as maliciouscode may grant itself all the necessary permissions it needs tosuccessfully mount an attack on the system.
`createPolicy.{policy type}`	Getting an instance of a Policy via Policy.getInstance	Granting this permission enables code to obtain a Policyobject. Malicious code may query the Policy object to determinewhat permissions have been granted to code other than itself.
`getProperty.{key}`	Retrieval of the security property with the specified key	Depending on the particular key for which access has beengranted, the code may have access to the list of securityproviders, as well as the location of the system-wide and usersecurity policies. while revealing this information does notcompromise the security of the system, it does provide maliciouscode with additional information which it may use to better aim anattack.
`setProperty.{key}`	Setting of the security property with the specified key	This could include setting a security provider or defining thelocation of the system-wide security policy. Malicious code thathas permission to set a new security provider may set a rogueprovider that steals confidential information such as cryptographicprivate keys. In addition, malicious code with permission to setthe location of the system-wide security policy may point it to asecurity policy that grants the attacker all the necessarypermissions it requires to successfully mount an attack on thesystem.
`insertProvider.{provider name}`	Addition of a new provider, with the specified name	This would allow somebody to introduce a possibly maliciousprovider (e.g., one that discloses the private keys passed to it)as the highest-priority provider. This would be possible becausethe Security object (which manages the installed providers)currently does not check the integrity or authenticity of aprovider before attaching it.
`removeProvider.{provider name}`	Removal of the specified provider	This may change the behavior or disable execution of otherparts of the program. If a provider subsequently requested by theprogram has been removed, execution may fail. Also, if the removedprovider is not explicitly requested by the rest of the program,but it would normally be the provider chosen when a cryptographyservice is requested (due to its previous order in the list ofproviders), a different provider will be chosen instead, or nosuitable provider will be found, thereby resulting in programfailure.
`clearProviderProperties.{provider name}`	"Clearing" of a Provider so that it no longer contains theproperties used to look up services implemented by theprovider	This disables the lookup of services implemented by theprovider. This may thus change the behavior or disable execution ofother parts of the program that would normally utilize theProvider, 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 aparticular service implemented by the provider. By granting thispermission, you let code replace the service specification withanother one, thereby specifying a different implementation.
`removeProviderProperty.{provider name}`	Removal of properties from the specified Provider	This disables the lookup of services implemented by theprovider. They are no longer accessible due to removal of theproperties specifying their names and locations. This may changethe behavior or disable execution of other parts of the programthat would normally utilize the Provider, as described under the"removeProvider.{provider name}" permission.

The following permissions are associated with classes that havebeen deprecated:Identity,IdentityScope,Signer. Use of them is discouraged. See the applicableclasses for more information.

`java.security.SecurityPermission` Target Name	What the Permission Allows	Risks of Allowing this Permission
`setSystemScope`	Setting of the system identity scope	This would allow an attacker to configure the system identityscope with certificates that should not be trusted, therebygranting applet or application code signed with those certificatesprivileges that would have been denied by the system's originalidentity scope.
`setIdentityPublicKey`	Setting of the public key for an Identity	If the identity is marked as "trusted", this allows an attackerto introduce a different public key (e.g., its own) that is nottrusted by the system's identity scope, thereby granting applet orapplication code signed with that public key privileges that wouldhave been denied otherwise.
`setIdentityInfo`	Setting of a general information string for an Identity	This allows attackers to set the general description for anidentity. This may trick applications into using a differentidentity than intended or may prevent applications from finding aparticular identity.
`addIdentityCertificate`	Addition of a certificate for an Identity	This allows attackers to set a certificate for an identity'spublic key. This is dangerous because it affects the trustrelationship across the system. This public key suddenly becomestrusted 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'spublic key. This is dangerous because it affects the trustrelationship across the system. This public key suddenly becomesconsidered less trustworthy than it otherwise would be.
`printIdentity`	Viewing the name of a principal and optionally the scope inwhich it is used, and whether or not it is considered "trusted" inthat scope.	The scope that is printed out may be a filename, in which caseit may convey local system information. For example, here's asample printout of an identity named "carol", who is marked nottrusted in the user's identity database: carol[/home/luehe/identitydb.obj][not trusted]
`getSignerPrivateKey`	Retrieval of a Signer's private key	It is very dangerous to allow access to a private key; privatekeys are supposed to be kept secret. Otherwise, code can use theprivate key to sign various files and claim the signature came fromthe Signer.
`setSignerKeyPair`	Setting of the key pair (public key and private key) for aSigner	This would allow an attacker to replace somebody else's (the"target's") keypair with a possibly weaker keypair (e.g., a keypairof a smaller keysize). This also would allow the attacker to listenin on encrypted communication between the target and its peers. Thetarget's peers might wrap an encryption session key under thetarget's "new" public key, which would allow the attacker (whopossesses the corresponding private key) to unwrap the session keyand decipher the communication data encrypted under that sessionkey.

`UnresolvedPermission`

Thejava.security.UnresolvedPermissionclass is used to holdPermissions that were"unresolved" when thePolicy was initialized. Anunresolved permission is one whose actualPermissionclass does not yet exist at the time thePolicy isinitialized (see below).

The policy for a Java runtime (specifying which permissions areavailable for code from various principals) is represented by aPolicy object. Whenever aPolicy isinitialized or refreshed,Permission objects ofappropriate classes are created for all permissions allowed by thePolicy.

Many permission class types referenced by the policyconfiguration are ones that exist locally (i.e., ones that can befound on CLASSPATH). Objects for such permissions can beinstantiated duringPolicy initialization. Forexample, it is always possible to instantiate ajava.io.FilePermission, since theFilePermission class is found on the CLASSPATH.

Other permission classes may not yet exist duringPolicy initialization. For example, a referencedpermission class may be in a JAR file that will later be loaded.For each such class, anUnresolvedPermission isinstantiated. Thus, anUnresolvedPermission isessentially a "placeholder" containing information about thepermission.

Later, when code callsAccessController.checkPermission on a permission of atype that was previously unresolved, but whose class has since beenloaded, previously-unresolved permissions of that type are"resolved". That is, for each suchUnresolvedPermission, a new object of the appropriateclass type is instantiated, based on the information in theUnresolvedPermission. This new object replaces theUnresolvedPermission, which is removed.

`AWTPermission`

Ajava.awt.AWTPermissionis for AWT permissions.

The following table lists all the possibleAWTPermission target names, and for each provides adescription of what the permission allows and a discussion of therisks 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 AWTclipboard	This would allow malfeasant code to share potentially sensitiveor confidential information.
`accessEventQueue`	Access to the AWT event queue	After retrieving the AWT event queue, malicious code may peekat and even remove existing events from the system, as well as postbogus events which may purposefully cause the application or appletto misbehave in an insecure manner.
`accessSystemTray`	Access to the AWT SystemTray instance	This would allow malicious code to add tray icons to the systemtray. First, such an icon may look like the icon of some knownapplication (such as a firewall or anti-virus) and order a user todo something unsafe (with help of balloon messages). Second, thesystem tray may be glutted with tray icons so that no one could adda tray icon anymore.
`createRobot`	Create`java.awt.Robot` objects	The`java.awt.Robot` object allows code to generatenative-level mouse and keyboard events as well as read the screen.It could allow malicious code to control the system, run otherprograms, read the display, and deny mouse and keyboard access tothe user.
`fullScreenExclusive`	Enter full-screen exclusive mode	Entering full-screen exclusive mode allows direct access tolow-level graphics card memory. This could be used to spoof thesystem, 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 allAWT events dispatched in the system, allowing it to read all userinput (such as passwords). Each AWT event listener is called fromwithin the context of that event queue's`EventDispatchThread`, so if the accessEventQueuepermission is also enabled, malicious code could modify thecontents of AWT event queues system-wide, causing the applicationor 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 thedisplay enable malicious code to snoop on the activities of theuser.
`replaceKeyboardFocusManager`	Sets the`KeyboardFocusManager` for a particularthread.	When a SecurityManager is installed, the invoking thread mustbe granted this permission in order to replace the currentKeyboardFocusManager. If permission is not granted, aSecurityException will be thrown.
`setAppletStub`	Setting the stub which implements Applet containerservices	Malicious code could set an applet's stub and result inunexpected behavior or denial of service to an applet.
`setWindowsAlwaysOnTop`	Setting always-on-top property of the window:`Window.setAlwaysOnTop(boolean)`	The malicious window might make itself look and behave like areal full desktop, so that information entered by the unsuspectinguser is captured and subsequently misused.
`showWindowWithoutWarningBanner`	Display of a window without also displaying a banner warningthat the window was created by an applet	Without this warning, an applet may pop up windows without theuser knowing that they belong to an applet. Since users may makesecurity-sensitive decisions based on whether or not the windowbelongs to an applet (entering a username and password into adialog box, for example), disabling this warning banner may allowapplets to trick the user into entering such information.
`toolkitModality`	Creating TOOLKIT_MODAL dialogs and setting the TOOLKIT_EXCLUDEwindow property.	When a toolkit-modal dialog is shown from an applet, it blocksall other applets in the browser. When launching applications fromJava Web Start, its windows (such as the security dialog) may alsobe blocked by toolkit-modal dialogs, shown from theseapplications.
`watchMousePointer`	Getting the information about the mouse pointer position at anytime	Constantly watching the mouse pointer, an applet can makeguesses about what the user is doing, i.e. moving the mouse to thelower left corner of the screen most likely means that the user isabout to launch an application. If a virtual keypad is used so thatkeyboard is emulated using the mouse, an applet may guess what isbeing typed.

`FilePermission`

Ajava.io.FilePermissionrepresents access to a file or directory. AFilePermission consists of a pathname and a set ofactions valid for that pathname.

Pathname is the pathname of the file or directory granted thespecified actions. A pathname that ends in "/*" (where "/" is thefile separator character,File.separatorChar)indicates a directory and all the files contained in thatdirectory. A pathname that ends with "/-" indicates (recursively) all files andsubdirectories contained in that directory. A pathname consisting of the special token "<<ALLFILES>>" matchesany file.

A pathname consisting of a single "*" indicates all the files inthe 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 currentdirectory.

The actions to be granted are passed to the constructor in astring 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:

Keyword	Meaning
`read`	Permission to read.
`write`	Permission to write (which includes permission tocreate).
`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 beforeprocessing.

Be careful when grantingFilePermissions. Thinkabout the implications of granting read and especially write accessto various files and directories. The "<<ALL FILES>>"permission with write action is especially dangerous. This grantspermission to write to the entire file system. One thing thiseffectively allows is replacement of the system binary, includingthe JVM runtime environment.

Note: Code can always read a file from the same directory it is in (or a subdirectory of that directory); it does not need explicit permission to do so. Code can also obtain the pathname of the directory it is executed from, and this pathname may contain sensitive information. For example, if code is executed from a home directory (or a subdirectory of the home directory), the pathname may reveal the name of the current user.

`SerializablePermission`

Ajava.io.SerializablePermissionis for serializable permissions. ASerializablePermission contains a name (also referredto as a "target name") but no actions list; you either have thenamed permission or you don't.

The target name is the name of the Serializable permission (seebelow).

The following table lists all the possibleSerializablePermission target names, and for eachprovides a description of what the permission allows and adiscussion 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 defaultserialization or deserialization, respectively, of objects	Code can use this to serialize or deserialize classes in apurposefully malfeasant manner. For example, during serialization,malicious code can use this to purposefully store confidentialprivate field data in a way easily accessible to attackers. Or,during deserializaiton it could, for example, deserialize a classwith all its private fields zeroed out.
`enableSubstitution`	Substitution of one object for another during serialization ordeserialization	This is dangerous because malicious code can replace the actualobject with one which has incorrect or malignant data.

`ReflectPermission`

Ajava.lang.reflect.ReflectPermissionis for reflective operations. A ReflectPermission is anamedpermission and has no actions. The only name currently definedissuppressAccessChecks, which allows suppressing thestandard language access checks -- for public, default (package)access, protected, and private members -- performed by reflectedobjects at their point of use.

The following table provides a summary description of what thepermission allows, and discusses the risks of granting code thepermission.

java.lang.reflect.ReflectPermission Target Name	What the Permission Allows	Risks of Allowing this Permission
`suppressAccessChecks`	Warning:Extreme caution should be taken beforegranting this permission to code, for it provides the abilityto access fields and invoke methods in a class. This includes notonly public, but protected and private fields and methods aswell.	This is dangerous in that information (possibly confidential)and methods normally unavailable would be accessible to maliciouscode.

`RuntimePermission`

Ajava.lang.RuntimePermissionis for runtime permissions. ARuntimePermissioncontains a name (also referred to as a "target name") but noactions list; you either have the named permission or youdon't.

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

The following table lists all the possibleRuntimePermission target names, and for each providesa description of what the permission allows and a discussion of therisks 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. Maliciousapplications that can instantiate their own class loaders couldthen load their own rogue classes into the system. These newlyloaded classes could be placed into any protection domain by theclass loader, thereby automatically granting the classes thepermissions for that domain.
`getClassLoader`	Retrieval of a class loader (e.g., the class loader for thecalling class)	This would grant an attacker permission to get the class loaderfor a particular class. This is dangerous because having access toa class's class loader allows the attacker to load other classesavailable to that class loader. The attacker would typicallyotherwise 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 extensionswhen they need to lookup resources that might not exist in thesystem class loader. Granting setContextClassLoader permissionwould allow code to change which context class loader is used for aparticular thread, including system threads.
`enableContextClassLoaderOverride`	Subclass implementation of the thread context class loadermethods	The context class loader is used by system code and extensionswhen they need to lookup resources that might not exist in thesystem class loader. Granting enableContextClassLoaderOverridepermission would allow a subclass of Thread to override the methodsthat are used to get or set the context class loader for aparticular thread.
`setSecurityManager`	Setting of the security manager (possibly replacing an existingone)	The security manager is a class that allows applications toimplement a security policy. Granting the setSecurityManagerpermission would allow code to change which security manager isused by installing a different, possibly less restrictive securitymanager, thereby bypassing checks that would have been enforced bythe original security manager.
`createSecurityManager`	Creation of a new security manager	This gives code access to protected, sensitive methods that maydisclose information about other classes or the executionstack.
`getenv.{variable name}`	Reading of the value of the specified environment variable	This would allow code to read the value, or determine theexistence, of a particular environment variable. This is dangerousif the variable contains confidential data.
`exitVM.{exit status}`	Halting of the Java Virtual Machine with the specified exitstatus	This allows an attacker to mount a denial-of-service attack byautomatically forcing the virtual machine to halt. Note: The"exitVM." permission is automatically granted to all code loadedfrom the application class path, thus enabling applications toterminate themselves. Also, the "exitVM" permission is equivalentto "exitVM.".
`shutdownHooks`	Registration and cancellation of virtual-machine shutdownhooks	This allows an attacker to register a malicious shutdown hookthat interferes with the clean shutdown of the virtualmachine.
`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 thesocket, server socket, stream handler, or RMI socket factory. Anattacker may set a faulty implementation which mangles the datastream.
`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 anyerror 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 behavior of any thread inthe system.
`stopThread`	Stopping of threads via calls to the Thread`stop`method	This allows code to stop any thread in the system provided thatit is already granted permission to access that thread. This posesas a threat, because that code may corrupt the system by killingexisting 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 theirrun priority.
`getProtectionDomain`	Retrieval of the`ProtectionDomain` for a class	This allows code to obtain policy information for a particularcode source. While obtaining policy information does not compromisethe security of the system, it does give attackers additionalinformation, such as local file names for example, to better aim anattack.
`getFileSystemAttributes`	Retrieval of file system attributes	This allows code to obtain file system information such as diskusage or disk space available to the caller. This is potentiallydangerous because it discloses information about the systemhardware configuration and some information about the caller'sprivilege to write files.
`readFileDescriptor`	Reading of file descriptors	This would allow code to read the particular file associatedwith the file descriptor read. This is dangerous if the filecontains confidential data.
`writeFileDescriptor`	Writing to file descriptors	This allows code to write to a particular file associated withthe descriptor. This is dangerous because it may allow malicouscode to plant viruses or at the very least, fill up your entiredisk.
`loadLibrary.{library name}`	Dynamic linking of the specified library	It is dangerous to allow an applet permission to load nativecode libraries, because the Java security architecture is notdesigned to and does not prevent malicious behavior at the level ofnative code.
`accessClassInPackage. {package name}`	Access to the specified package via a class loader's`loadClass` method when that class loader calls theSecurityManager`checkPackageAcesss` method	This gives code access to classes in packages to which itnormally does not have access. Malicious code may use these classesto help in its attempt to compromise security in the system.
`defineClassInPackage. {package name}`	Definition of classes in the specified package, via a classloader's`defineClass` method when that class loadercalls the SecurityManager`checkPackageDefinition`method.	This grants code permission to define a class in a particularpackage. This is dangerous because malicious code with thispermission may define rogue classes in trusted packages like`java.security` or`java.lang`, forexample.
`accessDeclaredMembers`	Warning:Extreme caution should be taken beforegranting this permission to code, for it provides access to thedeclared members of a class.	This grants code permission to query a class for its public,protected, default (package) access, and private fields and/ormethods. Although the code would have access to the private andprotected field and method names, it would not have access to theprivate/protected field data and would not be able to invoke anyprivate methods. Nevertheless, malicious code may use thisinformation to better aim an attack. Additionally, it may invokeany public methods and/or access public fields in the class. Thiscould be dangerous if the code would normally not be able to invokethose methods and/or access the fields because it can't cast theobject 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 simplywaste paper.
`getStackTrace`	Retrieval of the stack trace information of anotherthread.	This allows retrieval of the stack trace information of anotherthread. This might allow malicious code to monitor the execution ofthreads and discover vulnerabilities in applications.
`setDefaultUncaughtExceptionHandler`	Setting the default handler to be used when a thread terminatesabruptly due to an uncaught exception.	This allows an attacker to register a malicious uncaughtexception handler that could interfere with termination of athread.
`preferences`	Represents the permission required to get access to thejava.util.prefs.Preferences implementations user or system rootwhich in turn allows retrieval or update operations within thePreferences persistent backing store.	This permission allows the user to read from or write to thepreferences backing store if the user running the code hassufficient OS privileges to read/write to that backing store. Theactual backing store may reside within a traditional filesystemdirectory or within a registry depending on the platform OS.

NIO-Related Targets

Two NIO-relatedRuntimePermission targets were addedin the 1.4 release of the JavaSE JDK:

selectorProvidercharsetProvider

TheseRuntimePermissions are required to be granted toclasses which subclass and implementjava.nio.channel.spi.SelectorProvider orjava.nio.charset.spi.CharsetProvider. The permissionis checked during invocation of the abstract base classconstructor. These permissions ensure trust in classes whichimplement these security-sensitive provider mechanisms.

Seejava.nio.channels.spi.SelectorProviderandjava.nio.channels.spi.CharsetProviderfor more information.

`NetPermission`

Ajava.net.NetPermissionis for various network permissions. ANetPermissioncontains a name but no actions list; you either have the namedpermission or you don't.

The following table lists all the possibleNetPermission target names, and for each provides adescription of what the permission allows and a discussion of therisks 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 isretrieved when a proxy or HTTP server asks for authentication	Malicious code can set an authenticator that monitors andsteals user authentication input as it retrieves the input from theuser.
`requestPasswordAuthentication`	The ability to ask the authenticator registered with the systemfor a password	Malicious code may steal this password.
`specifyStreamHandler`	The ability to specify a stream handler when constructing aURL	Malicious code may create a URL with resources that it wouldnormally not have access to (like file:/foo/fum/), specifying astream handler that gets the actual bytes from someplace it doeshave access to. Thus it might be able to trick the system intocreating a ProtectionDomain/CodeSource for a class even though thatclass really didn't come from that location.
`setProxySelector`	The ability to set the proxy selector used to make decisions onwhich proxies to use when making network connections.	Malicious code can set a ProxySelector that directs networktraffic to an arbitrary network host.
`getProxySelector`	The ability to get the proxy selector used to make decisions onwhich proxies to use when making network connections.	Malicious code can get a ProxySelector to discover proxy hostsand ports on internal networks, which could then become targets forattack.
`setCookieHandler`	The ability to set the cookie handler that processes highlysecurity sensitive cookie information for an Http session.	Malicious code can set a cookie handler to obtain access tohighly security sensitive cookie information. Some web servers usecookies to save user private information such as access controlinformation, or to track user browsing habit.
`getCookieHandler`	The ability to get the cookie handler that processes highlysecurity sensitive cookie information for an Http session.	Malicious code can get a cookie handler to obtain access tohighly security sensitive cookie information. Some web servers usecookies to save user private information such as access controlinformation, or to track user browsing habit.
`setResponseCache`	The ability to set the response cache that provides access to alocal response cache.	Malicious code getting access to the local response cache couldaccess security sensitive information, or create false entries inthe response cache.
`getResponseCache`	The ability to get the response cache that provides access to alocal response cache.	Malicious code getting access to the local response cache couldaccess security sensitive information.

`SocketPermission`

Ajava.net.SocketPermissionrepresents access to a network via sockets. A SocketPermissionconsists of a host specification and a set of "actions" specifyingways to connect to that host. The host is specified as

host = (hostname | IPaddress)[:portrange]portrange = portnumber | -portnumber | portnumber-[portnumber]

The host is expressed as a DNS name, as a numerical IP address,or as "localhost" (for the local machine). The wildcard "*" may beincluded 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 theform "N-", whereN is a port number, signifies all portsnumberedN and above, while a specification of the form "-N"indicates all ports numberedN and below.

The possible ways to connect to the host are

acceptconnectlistenresolve

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.example.com:7777", "connect, accept";};

this causes the following permission object to be generated andgranted to code signed by "mrm."

p1 = new SocketPermission("puffin.example.com:7777", "connect,accept");

p1 represents a permission allowing connections toport 7777 onpuffin.example.com, and also acceptingconnections on that port.

Similarly, if you have the following entry in your policy:

grant signedBy "paul" {    permission java.net.SocketPermission "localhost:1024-", "accept, connect, listen";};

this causes the following permission object to be generated andgranted to code signed by "paul."

p2 = new SocketPermission("localhost:1024-", "accept,connect,listen");

p2 represents a permission allowing acceptingconnections on, connecting to, or listening on any port between1024 and 65535 on the local host.

Note: Granting code permission to accept or makeconnections to remote hosts may be dangerous because malevolentcode can then more easily transfer and share confidential dataamong parties who may not otherwise have access to the data.

`SQLPermission`

The permission for which theSecurityManager willcheck when code that is running in an applet, or an applicationwith an instance ofSecurityManager enabled, calls oneof the following methods:

java.sql.DriverManager.setLogWriter
java.sql.DriverManager.setLogStream(deprecated)
javax.sql.rowset.spi.SyncFactory.setJNDIContext
javax.sql.rowset.spi.SyncFactory.setLogger
java.sql.Connection.setNetworktimeout
java.sql.Connection.abort

If there is noSQLPermission object, these methodsthrow ajava.lang.SecurityException as a runtimeexception.

ASQLPermission object contains a name (alsoreferred to as a "target name") but no actions list; there iseither a named permission or there is not. The target name is thename of the permission (see the following table that lists all thepossibleSQLPermission names). The naming conventionfollows the hierarchical property naming convention. In addition,an asterisk (*) may appear at the end of the name,following a dot (.), or by itself, to signify awildcard match. For example:loadLibrary.* or* is valid, but*loadLibrary ora*b is not valid.

The following table lists all the possibleSQLPermission target names. The table gives adescription of what the permission allows and a discussion of therisks of granting code the permission.

Permission Target Name	What Permission Allows	Risks of Allowing This Permission
setLog	Setting of the logging stream	This is a dangerous permission to grant. The contents of thelog can contain usernames and passwords, SQL statements, and SQLdata.
callAbort	Invocation of the`Connection` method`abort`	Permits an application to terminate a physical connection to adatabase.
setSyncFactory	Invocation of the`SyncFactory` methods`setJNDIContext` and`setLogger`	Permits an application to specify the JNDI context from whichthe`SyncProvider` implementations can be retrieved fromand the logging object to be used by the`SyncProvider`implementation.
setNetworkTimeout	Invocation of the`Connection` method`setNetworkTimeout`	Permits an application to specify the maximum period a`Connection` or objects created from the`Connection` object will wait for the database to replyto any one request.

The person running an applet decides what permissions to allowand runs thePolicy Tool to create an instance ofSQLPermission in a policy file. A programmer does notuse a constructor directly to create an instance ofSQLPermission but rather uses a tool.

`PropertyPermission`

Ajava.util.PropertyPermissionis for property permissions.

The name is the name of the property ("java.home", "os.name",etc). The naming convention follows the hierarchical propertynaming convention. Also, an asterisk may appear at the end of thename, following a ".", or by itself, to signify a wildcard match.For example: "java.*" or "*" is valid, "*java" or "a*b" is notvalid.

The actions to be granted are passed to the constructor in astring containing a list of zero or more comma-separated keywords.The possible keywords are "read" and "write". Their meaning isdefined as follows:

Keyword	Meaning
`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 beforeprocessing.

Care should be taken before granting code permission to accesscertain system properties. For example, granting permission toaccess the "java.home" system property gives potentially malevolentcode sensitive information about the system environment (thelocation of the runtime environment's directory). Also, grantingpermission to access the "user.name" and "user.home" systemproperties gives potentially malevolent code sensitive informationabout the user environment (the user's account name and homedirectory).

`LoggingPermission`

ASecurityManager will check thejava.util.logging.LoggingPermissionobject when code running with aSecurityManager callsone of the logging control methods (such asLogger.setLevel).

Currently there is only one namedLoggingPermission, "control".control grants the ability to control the loggingconfiguration; for example by adding or removing Handlers, byadding or removing Filters, or by changing logging levels.

Normally you do not createLoggingPermissionobjects directly; instead they are created by the security policycode based on reading the security policy file.

`SSLPermission`

Thejavax.net.ssl.SSLPermissionclass is for various network permissions. AnSSLPermission contains a name (also referred to as a"target name") but no actions list; you either have the namedpermission or you don't.

The target name is the name of the network permission (seebelow). The naming convention follows the hierarchical propertynaming convention. Also, an asterisk may appear at the end of thename, following a ".", or by itself, to signify awildcard match. For example: "foo.*" or"*" is valid, "*foo" or"a*b" is not valid.

The following table lists all the possible SSLPermission targetnames, and for each provides a description of what the permissionallows and a discussion of the risks of granting code thepermission.

Permission Target Name	What the Permission Allows	Risks of Allowing this Permission
`setHostnameVerifier`	The ability to set a callback which can decide whether to allowa mismatch between the host being connected to by an`HttpsURLConnection` and the common name field in servercertificate.	Malicious code can set a verifier that monitors host namesvisited by`HttpsURLConnection` requests or that allowsserver certificates with invalid common names.
`getSSLSessionContext`	The ability to get the`SSLSessionContext` of an`SSLSession`.	Malicious code may monitor sessions which have been establishedwith SSL peers or might invalidate sessions to slow downperformance.
`setDefaultSSLContext`	The ability to set the default SSL context.	When applications use default SSLContext, by setting thedefault SSL context, malicious code may use unproved trustmaterial, key material and random generator, or use dangerous SSLsocket factory and SSL server socket factory.

`AuthPermission`

Thejavax.security.auth.AuthPermissionclass is for authentication permissions. AnAuthPermission contains a name (also referred to as a"target name") but no actions list; you either have the namedpermission or you don't.

Currently theAuthPermission object is used toguard access to theSubject,SubjectDomainCombiner,LoginContext andConfiguration objects.

The following table lists all the possibleAuthPermission target names, and for each provides adescription of what the permission allows and a discussion of therisks of granting code the permission.

Permission Target Name	What the Permission Allows	Risks of Allowing this Permission
`doAs`	Invocation of the`Subject.doAs` methods	This enables an application to invoke code (Actions) under theidentity of any`Subject` specified to the`doAs` method.
`doAsPrivileged`	Invocation of the`Subject.doAsPrivileged`methods	This enables an application to invoke code (Actions) under theidentity of any`Subject` specified to the`doAsPrivileged` method. Additionally, the caller mayremove itself from the call stack (and hence from subsequentsecurity decisions) if it passes`null` as the`AccessControlContext`.
`getSubject`	Retrieving the`Subject` from the provided`AccessControlContext`	This permits an application to gain access to an authenticated`Subject`. The application can then access the Subject'sauthenticated Principals and public credentials.
`getSubjectFromDomainCombiner`	Retrieving the`Subject` from a`SubjectDomainCombiner`	This permits an application to gain access to the authenticated`Subject` associated with a`SubjectDomainCombiner`. The application can then accessthe Subject's authenticated Principals and public credentials.
`setReadOnly`	Setting a`Subject` read-only	This permits an application to set a Subject's`Principal`, public credential and private credentialsets to be read-only. This can be potentially used as a type ofdenial of service attack.
`modifyPrincipals`	Make modifications to a Subject's`Principal`set	Access control decisions are based on the Principals associatedwith a`Subject`. This permission permits an applicationto make any modifications to a Subject's`Principal`set, thereby affecting subsequent security decisions.
`modifyPublicCredentials`	Make modifications to a Subject's public credential set	This permission permits an application to add or remove publiccredentials from a`Subject`. This may affect code thatrelies on the proper set of private credentials to exist in that`Subject`.
`modifyPrivateCredentials`	Make modifications to a Subject's private credential set	This permission permits an application to add or remove privatecredentials from a`Subject`. This may affect code thatrelies on the proper set of private credentials to exist in that`Subject`.
`refreshCredential`	Refresh a credential`Object` that implements the`Refreshable` interface	This permission permits an application to refresh a credentialthat is intended to expire.
`destroyCredential`	Destroy a credential`Object` that implements the`Destroyable` interface	This permission permits an application to potentially destroy acredential as a denial of service attack.
`createLoginContext.{name}`	Instantiate a`LoginContext` with the specifiedname	For security purposes, an administrator might not want anapplication to be able to authenticate to any`LoginModule`. This permission permits an application toauthenticate to the LoginModules configured for the specifiedname.
`getLoginConfiguration`	Retrieve the system-wide login`Configuration`	Allows an application to determine all the LoginModules thatare configured for every application in the system.
`setLoginConfiguration`	Set the system-wide login`Configuration`	Allows an application to configure the LoginModules for everyapplication in the system.
`createLoginConfiguration.{configuration type}`	Obtain a Configuration object viaConfiguration.getInstance	Allows an application to see all the LoginModules that arespecified in the configuration.
`refreshLoginConfiguration`	Refresh the system-wide login`Configuration`	Allows an application to refresh the login`Configuration`.

`PrivateCredentialPermission`

Thejavax.security.auth.PrivateCredentialPermissionclass is used to protect access to private Credentials belonging toa particularSubject. TheSubject is representedby a Set of Principals.

The target name of thisPermission specifies aCredential class name, and a Set of Principals. Theonly valid value for thisPermission's actions is,"read". The target name must abide by the following syntax:

CredentialClass {PrincipalClass "PrincipalName"}*

For example, the following permission grants access to thecom.sun.PrivateCredential owned bySubjects which have acom.sun.Principalwith the name, "duke".

Note: Although this example, as well as all the examplesbelow, do not containCodebase,SignedBy,orPrincipal information in the grant statement (forsimplicity reasons), actual policy configurations should specifythat information when appropriate.

grant {    permission javax.security.auth.PrivateCredentialPermission             "com.sun.PrivateCredential com.sun.Principal \"duke\"",             "read";};

IfCredentialClass is "*", then access isgranted to all privateCredentials belonging to thespecifiedSubject. If "PrincipalName" is"*", then access is granted to the specifiedCredential owned by anySubject that has thespecifiedPrincipal (the actualPrincipalNamedoesn't matter). For example, the following grants access to thea.b.Credential owned by anySubject that hasana.b.Principal.

grant {    permission javax.security.auth.PrivateCredentialPermission             "a.b.Credential a.b.Principal "*"",             "read";};

If both thePrincipalClass and"PrincipalName" are "*", then access isgranted to the specifiedCredential owned by anySubject. In addition, thePrincipalClass/PrincipalName pairing maybe repeated:

grant {    permission javax.security.auth.PrivateCredentialPermission             "a.b.Credential a.b.Principal "duke" c.d.Principal "dukette"",             "read";};

The above code grants access to the privateCredential, "a.b.Credential", belongingto aSubject with at least two associatedPrincipals: "a.b.Principal" with thename, "duke", and "c.d.Principal", withthe name, "dukette".

`DelegationPermission`

Thejavax.security.auth.kerberos.DelegationPermissionclass is used to restrict the usage of the Kerberos delegationmodel; ie, forwardable and proxiable tickets.

The target name of this Permission specifies a pair of kerberosservice principals. The first is the subordinate service principalbeing entrusted to use the Ticket Granting Ticket (TGT). The secondservice principal designates the target service the subordinateservice principal is to interact with on behalf of the initiatingKerberosPrincipal. This latter service principal isspecified to restrict the use of a proxiable ticket.

For example, to specify the "host" service use of a forwardableTGT, the target permission is specified as follows:

DelegationPermission("\"host/foo.example.com@EXAMPLE.COM\" \"krbtgt/EXAMPLE.COM@EXAMPLE.COM\"");

To give the "backup" service a proxiable NFS service ticket, thetarget permission might be specified:

DelegationPermission("\"backup/bar.example.com@EXAMPLE.COM\" \"nfs/home.EXAMPLE.COM@EXAMPLE.COM\"");

`ServicePermission`

Thejavax.security.auth.kerberos.ServicePermission class isused to protect Kerberos services and the credentials necessary toaccess those services. There is a one to one mapping of a serviceprincipal and the credentials necessary to access the service.Therefore granting access to a service principal implicitly grantsaccess to the credential necessary to establish a security contextwith the service principal. This applies regardless of whether thecredentials are in a cache or acquired via an exchange with theKDC. The credential can be either a ticket granting ticket, aservice ticket or a secret key from a key table.

AServicePermission contains a service principalname and a list of actions which specify the context the credentialcan be used within.

The service principal name is the canonical name of theKereberosPrincipal supplying the service, that is theKerberosPrincipal represents a Kerberos serviceprincipal. This name is treated in a case sensitive manner.

Granting this permission implies that the caller can use acached credential (Ticket Granting Ticket, service ticket or secretkey) within the context designated by the action. In the case ofthe TGT, granting this permission also implies that the TGT can beobtained by anAuthentication Service exchange.

The possible actions are:

Action	Meaning
`initiate`	Allows the caller to use the credential to initiatea security context with a service principal.
`accept`	Allows the caller to use the credential to acceptsecurity context as a particular principal.

For example, to specify the permission to access to the TGT toinitiate a security context the permission is constructed asfollows:

     ServicePermission("krbtgt/EXAMPLE.COM@EXAMPLE.COM", "initiate");

To obtain a service ticket to initiate a context with the "host"service the permission is constructed as follows:

ServicePermission("host/foo.example.com@EXAMPLE.COM", "initiate");

For a Kerberized server the action is "accept". For example, thepermission necessary to access and use the secret key of theKerberized "host" service (telnet and the likes) would beconstructed as follows:

ServicePermission("host/foo.example.com@EXAMPLE.COM", "accept");

`AudioPermission`

Thejavax.sound.sampled.AudioPermissionclass represents access rights to the audio system resources. AnAudioPermission contains a target name but no actionslist; you either have the named permission or you don't.

The target name is the name of the audio permission (see thetable below). The names follow the hierarchical property-namingconvention. Also, an asterisk can be used to represent all theaudio permissions.

The following table lists the possibleAudioPermission target names. For each name, the tableprovides a description of exactly what that permission allows, aswell as a discussion of the risks of granting code thepermission.

Permission Target Name	What the Permission Allows	Risks of Allowing this Permission
`play`	Audio playback through the audio device or devices on thesystem. Allows the application to obtain and manipulate lines andmixers for audio playback (rendering).	In some cases use of this permission may affect otherapplications because the audio from one line may be mixed withother audio being played on the system, or because manipulation ofa mixer affects the audio for all lines using that mixer.
`record`	Audio recording through the audio device or devices on thesystem. Allows the application to obtain and manipulate lines andmixers for audio recording (capture).	In some cases use of this permission may affect otherapplications because manipulation of a mixer affects the audio forall lines using that mixer. This permission can enable an applet orapplication to eavesdrop on a user.

Methods andthe Permissions They Require

The following table contains a list of all the methods thatrequire permissions, and for each tells whichSecurityManager method it calls and which permissionis checked for by the default implementation of thatSecurityManager method.

Thus, with the defaultSecurityManager methodimplementations, a call to a method in the left-hand column canonly be successful if the permission specified in the correspondingentry in the right-hand column is allowed by the policy currentlyin 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 thegetSystemEventQueuemethod in thejava.awt.Toolkit class results in a callto thecheckAwtEventQueueAccess SecurityManagermethod, which can only be successful if the following permission isgranted 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 offoo replaces the string{foo} in the permission name.

As an example, here is one table entry:

Method	SecurityManager Method Called	Permission
java.io.FileInputStream FileInputStream(String name)	`checkRead(String)`	`java.io.FilePermission "{name}", "read";`

If theFileInputStream method (in this case, aconstructor) is called with "/test/MyTestFile" as thename argument, as in

  FileInputStream("/test/MyTestFile");

then in order for the call to succeed, the following permissionmust be set in the current policy, allowing read access to the file"/test/MyTestFile":

  java.io.FilePermission "/test/MyTestFile", "read";

More specifically, the permission must either be explicitly set,as above, or implied by another permission, such as thefollowing:

  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 thename of a specific method argument but is meant to represent therelevant value. Here is an example:

Method	SecurityManager Method Called	Permission
java.net.DatagramSocket public synchronized void receive(DatagramPacket p);	`checkAccept({host}, {port})`	`java.net.SocketPermission "{host}:{port}","accept";`

Here, the appropriate host and port values are calculated by thereceive method and passed tocheckAccept.

In most cases, just the name of the SecurityManager methodcalled is listed. Where the method is one of multiple methods ofthe same name, the argument types are also listed, for example forcheckRead(String) andcheckRead(FileDescriptor). In other cases wherearguments may be relevant, they are also listed.

The following table is ordered by package name. That is, themethods in classes in thejava.awt package are listedfirst, followed by methods in classes in thejava.iopackage, and so on.

	SecurityManager Method Called	Permission
java.awt.Graphics2d public abstract void setComposite(Composite comp)	checkPermission	java.awt.AWTPermission "readDisplayPixels" if this Graphics2Dcontext is drawing to a Component on the display screen and theComposite is a custom object rather than an instance of theAlphaComposite class. Note: The setComposite method is actuallyabstract and thus can't invoke security checks. Each actualimplementation of the method should call thejava.lang.SecurityManager checkPermission method with ajava.awt.AWTPermission("readDisplayPixels") permission under theconditions 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)	checkPermission	java.awt.AWTPermission "listenToAllAWTEvents"
java.awt.Toolkit public abstract PrintJob getPrintJob( Frame frame, String jobtitle, Properties props)	checkPrintJobAccess	java.lang.RuntimePermission "queuePrintJob" Note: The getPrintJob method is actually abstract and thus can'tinvoke security checks. Each actual implementation of the methodshould call the java.lang.SecurityManager checkPrintJobAccessmethod, 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 andthus can't invoke security checks. Each actual implementation ofthe method should call the java.lang.SecurityManagercheckSystemClipboardAccess method, which is successful only if thejava.awt.AWTPermission "accessClipboard" permission is currentlyallowed.
java.awt.Toolkit public final EventQueue getSystemEventQueue()	checkAwtEventQueueAccess	java.awt.AWTPermission "accessEventQueue"
java.awt.Window Window()	checkTopLevelWindow	If java.awt.AWTPermission "showWindowWithoutWarningBanner" isset, the window will be displayed without a banner warning that thewindow was created by an applet. It it's not set, such a bannerwill 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()	checkDelete(String)	java.io.FilePermission "{name}", "delete"
java.io.FileInputStream FileInputStream(FileDescriptor fdObj)	checkRead(FileDescriptor)	java.lang.RuntimePermission "readFileDescriptor"
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)	checkRead(String)	java.io.FilePermission "{name}", "read"
java.io.FileOutputStream FileOutputStream(FileDescriptor fdObj)	checkWrite(FileDescriptor)	java.lang.RuntimePermission "writeFileDescriptor"
java.io.FileOutputStream FileOutputStream(File file) FileOutputStream(String name) FileOutputStream(String name, boolean append)java.io.File public boolean canWrite() public boolean createNewFile() public static File createTempFile( String prefix, String suffix) public static File createTempFile( String prefix, String suffix, File directory) public boolean mkdir() public boolean mkdirs() public boolean renameTo(File dest) public boolean setLastModified(long time) public boolean setReadOnly()	checkWrite(String)	java.io.FilePermission "{name}", "write"
java.io.ObjectInputStream protected final boolean enableResolveObject(boolean enable);java.io.ObjectOutputStream protected final boolean enableReplaceObject(boolean enable)	checkPermission	java.io.SerializablePermission "enableSubstitution"
java.io.ObjectInputStream protected ObjectInputStream()java.io.ObjectOutputStream protected ObjectOutputStream()	checkPermission	java.io.SerializablePermission"enableSubclassImplementation"
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 loaderis not null, thenjava.lang.RuntimePermission("getClassLoader")
java.lang.Class public ClassLoader getClassLoader()	checkPermission	If the caller's class loader is null, or is the same as or anancestor of the class loader for the class whose class loader isbeing 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 isin 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}" isalso required.
java.lang.Class public Class[] getClasses() 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 apackage, checkPackageAccess({pkgName})	Default checkMemberAccess does not require any permissions whenthe access type is Member.PUBLIC. If this class is in a package,java.lang.RuntimePermission "accessClassInPackage.{pkgName}" isrequired.
java.lang.Class public ProtectionDomain getProtectionDomain()	checkPermission	java.lang.RuntimePermission "getProtectionDomain"
java.lang.ClassLoader ClassLoader() ClassLoader(ClassLoader parent)	checkCreateClassLoader	java.lang.RuntimePermission "createClassLoader"
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 anancestor of the class loader for the class whose class loader isbeing 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 forrunFinalizersOnExit	java.lang.RuntimePermission "exitVM.{status}"
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 orlibname argument	java.lang.RuntimePermission "loadLibrary.{libName}"
java.lang.SecurityManager methods	checkPermission	See thenext table.
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 anancestor of the context class loader for the thread whose contextclass loader is being requested, no permission is needed.Otherwise, java.lang.RuntimePermission "getClassLoader" is required.
java.lang.Thread public void setContextClassLoader (ClassLoader cl)	checkPermission	java.lang.RuntimePermission "setContextClassLoader"
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 threadis trying to stop a thread other than itself.	java.lang.RuntimePermission "modifyThread". Also java.lang.RuntimePermission "stopThread" if the current threadis 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 threadis trying to stop a thread other than itself or obj is not aninstance of ThreadDeath.	java.lang.RuntimePermission "modifyThread". Also java.lang.RuntimePermission "stopThread" if the current threadis trying to stop a thread other than itself or obj is not aninstance of ThreadDeath.
java.lang.Thread Thread() Thread(Runnable target) Thread(String name) Thread(Runnable target, String name)java.lang.ThreadGroup ThreadGroup(String name) ThreadGroup(ThreadGroup parent, String name)	checkAccess({parentThreadGroup})	java.lang.RuntimePermission "modifyThreadGroup"
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, orcheckAccess(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 thejava.lang.Thread interrupt() method is called for each thread inthe thread group and in all of its subgroups. See the Threadinterrupt() method.
java.lang.ThreadGroup public final void stop()	checkAccess(this)	Requires java.lang.RuntimePermission "modifyThreadGroup". Also requires java.lang.RuntimePermission "modifyThread" andpossibly java.lang.RuntimePermission "stopThread", since thejava.lang.Thread stop() method is called for each thread in thethread group and in all of its subgroups. See the Thread stop()method.
java.lang.reflect.AccessibleObject public static void setAccessible(...) public void setAccessible(...)	checkPermission	java.lang.reflect.ReflectPermission "suppressAccessChecks"
java.net.Authenticator public static PasswordAuthentication requestPasswordAuthentication( InetAddress addr, int port, String protocol, String prompt, String scheme)	checkPermission	java.net.NetPermission "requestPasswordAuthentication"
java.net.Authenticator public static void setDefault(Authenticator a)	checkPermission	java.net.NetPermission "setDefaultAuthenticator"
java.net.MulticastSocket public void joinGroup(InetAddress mcastaddr) public void leaveGroup(InetAddress mcastaddr)	checkMulticast(InetAddress)	java.net.SocketPermission( mcastaddr.getHostAddress(),"accept,connect")
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()	checkConnect({host}, -1)	java.net.SocketPermission "{host}", "resolve"
java.net.ServerSocket ServerSocket(...)java.net.DatagramSocket DatagramSocket(...)java.net.MulticastSocket MulticastSocket(...)	checkListen({port})	if (port == 0) java.net.SocketPermission"localhost:1024-","listen"; else java.net.SocketPermission "localhost:{port}","listen"
java.net.ServerSocket public Socket accept() protected final void implAccept(Socket s)	checkAccept({host}, {port})	java.net.SocketPermission "{host}:{port}", "accept"
java.net.ServerSocket public static synchronized void setSocketFactory(...)java.net.Socket public static synchronized void setSocketImplFactory(...)java.net.URL public static synchronized void setURLStreamHandlerFactory(...) java.net.URLConnection public static synchronized void setContentHandlerFactory(...) public static void setFileNameMap(FileNameMap map)java.net.HttpURLConnection public static void setFollowRedirects(boolean set)java.rmi.activation.ActivationGroup public static synchronized ActivationGroup createGroup(...) public static synchronized void setSystem(ActivationSystem system)java.rmi.server.RMISocketFactory public synchronized static void setSocketFactory(...)	checkSetFactory	java.lang.RuntimePermission "setFactory"
java.net.Socket Socket(...)	checkConnect({host}, {port})	java.net.SocketPermission "{host}:{port}", "connect"
java.net.DatagramSocket public synchronized void receive(DatagramPacket p)	checkAccept({host}, {port})	java.net.SocketPermission "{host}:{port}", "accept"
java.net.URL URL(...)	checkPermission	java.net.NetPermission "specifyStreamHandler"
java.net.URLClassLoader URLClassLoader(...)	checkCreateClassLoader	java.lang.RuntimePermission "createClassLoader"
java.security.AccessControlContext public AccessControlContext(AccessControlContext acc, DomainCombiner combiner) public DomainCombiner getDomainCombiner()	checkPermission	java.security.SecurityPermission"createAccessControlContext"
java.security.Identity public void addCertificate(...)	checkSecurityAccess( "addIdentityCertificate")	java.security.SecurityPermission "addIdentityCertificate"
java.security.Identity public void removeCertificate(...)	checkSecurityAccess( "removeIdentityCertificate")	java.security.SecurityPermission"removeIdentityCertificate"
java.security.Identity public void setInfo(String info)	checkSecurityAccess( "setIdentityInfo")	java.security.SecurityPermission "setIdentityInfo"
java.security.Identity public void setPublicKey(PublicKey key)	checkSecurityAccess( "setIdentityPublicKey")	java.security.SecurityPermission "setIdentityPublicKey"
java.security.Identity public String toString(...)	checkSecurityAccess( "printIdentity")	java.security.SecurityPermission "printIdentity"
java.security.IdentityScope protected static void setSystemScope()	checkSecurityAccess( "setSystemScope")	java.security.SecurityPermission "setSystemScope"
java.security.Permission public void checkGuard(Object object)	checkPermission(this)	this Permission object is the permission checked
java.security.Policy public static Policy getPolicy()	checkPermission	java.security.SecurityPermission "getPolicy"
java.security.Policy public static void setPolicy(Policy policy)	checkPermission	java.security.SecurityPermission "setPolicy"
java.security.Policy public static Policy getInstance(String type, SpiParameter params) getInstance(String type, SpiParameter params, String provider) getInstance(String type, SpiParameter params, Provider provider)	checkPermission	java.security.SecurityPermission "createPolicy.{type}"
java.security.Provider public synchronized void clear()	checkSecurityAccess( "clearProviderProperties."+{name})	java.security.SecurityPermission"clearProviderProperties.{name}" wherename is the providername.
java.security.Provider public synchronized Object put(Object key, Object value)	checkSecurityAccess( "putProviderProperty."+{name})	java.security.SecurityPermission "putProviderProperty.{name}"wherename is the provider name.
java.security.Provider public synchronized Object remove(Object key)	checkSecurityAccess( "removeProviderProperty."+{name})	java.security.SecurityPermission"removeProviderProperty.{name}" wherename is the providername.
java.security.SecureClassLoader SecureClassLoader(...)	checkCreateClassLoader	java.lang.RuntimePermission "createClassLoader"
java.security.Security public static void getProperty(String key)	checkPermission	java.security.SecurityPermission "getProperty.{key}"
java.security.Security public static int addProvider(Provider provider) public static int insertProviderAt(Provider provider, int position);	checkSecurityAccess( "insertProvider."+provider.getName())	java.security.SecurityPermission "insertProvider.{name}"
java.security.Security public static void removeProvider(String name)	checkSecurityAccess( "removeProvider."+name)	java.security.SecurityPermission "removeProvider.{name}"
java.security.Security public static void setProperty(String key, String datum)	checkSecurityAccess( "setProperty."+key)	java.security.SecurityPermission "setProperty.{key}"
java.security.Signer public PrivateKey getPrivateKey()	checkSecurityAccess( "getSignerPrivateKey")	java.security.SecurityPermission "getSignerPrivateKey"
java.security.Signer public final void setKeyPair(KeyPair pair)	checkSecurityAccess( "setSignerKeypair")	java.security.SecurityPermission "setSignerKeypair"
java.sql.DriverManager public static synchronized void setLogWriter(PrintWriter out)	checkPermission	java.sql.SQLPermission "setLog"
java.sql.DriverManager public static synchronized void setLogStream(PrintWriter out)	checkPermission	java.sql.SQLPermission "setLog"
java.util.Locale public static synchronized void setDefault(Locale newLocale)	checkPermission	java.util.PropertyPermission "user.language","write"
java.util.zip.ZipFile ZipFile(String name)	checkRead	java.io.FilePermission "{name}","read"
javax.security.auth.Subject public static Subject getSubject(final AccessControlContext acc)	checkPermission	javax.security.auth.AuthPermission "getSubject"
javax.security.auth.Subject public void setReadOnly()	checkPermission	javax.security.auth.AuthPermission "setReadOnly"
javax.security.auth.Subject public static Object doAs(final Subject subject, final PrivilegedAction action)	checkPermission	javax.security.auth.AuthPermission "doAs"
javax.security.auth.Subject public static Object doAs(final Subject subject, final PrivilegedExceptionAction action) throws java.security.PrivilegedActionException	checkPermission	javax.security.auth.AuthPermission "doAs"
javax.security.auth.Subject public static Object doAsPrivileged(final Subject subject, final PrivilegedAction action, final AccessControlContext acc)	checkPermission	javax.security.auth.AuthPermission "doAsPrivileged"
javax.security.auth.Subject public static Object doAsPrivileged(final Subject subject, final PrivilegedExceptionAction action, final AccessControlContext acc) throws java.security.PrivilegedActionException	checkPermission	javax.security.auth.AuthPermission "doAsPrivileged"
javax.security.auth.SubjectDomainCombiner public Subject getSubject()	checkPermission	javax.security.auth.AuthPermission"getSubjectFromDomainCombiner"
javax.security.auth.SubjectDomainCombiner public Subject getSubject()	checkPermission	javax.security.auth.AuthPermission"getSubjectFromDomainCombiner"
javax.security.auth.login.LoginContext public LoginContext(String name) throws LoginException	checkPermission	javax.security.auth.AuthPermission"createLoginContext.{name}"
javax.security.auth.login.LoginContext public LoginContext(String name, Subject subject) throws LoginException	checkPermission	javax.security.auth.AuthPermission"createLoginContext.{name}"
javax.security.auth.login.LoginContext public LoginContext(String name, CallbackHandler callbackHandler) throws LoginException	checkPermission	javax.security.auth.AuthPermission"createLoginContext.{name}"
javax.security.auth.login.LoginContext public LoginContext(String name, Subject subject, CallbackHandler callbackHandler) throws LoginException	checkPermission	javax.security.auth.AuthPermission"createLoginContext.{name}"
javax.security.auth.login.Configuration public static Configuration getConfiguration()	checkPermission	javax.security.auth.AuthPermission "getLoginConfiguration"
javax.security.auth.login.Configuration public static void setConfiguration(Configuration configuration)	checkPermission	javax.security.auth.AuthPermission "setLoginConfiguration"
javax.security.auth.login.Configuration public static void refresh()	checkPermission	javax.security.auth.AuthPermission"refreshLoginConfiguration"
javax.security.auth.login.Configuration public static Configuration getInstance(String type, SpiParameter params) getInstance(String type, SpiParameter params, String provider) getInstance(String type, SpiParameter params, Provider provider)	checkPermission	javax.security.auth.AuthPermission"createLoginConfiguration.{type}"

java.lang.SecurityManager Method PermissionChecks

This table shows which permissions are checked for by thedefault implementations of thejava.lang.SecurityManager methods.

Each of the specifiedcheck methods calls theSecurityManagercheckPermission methodwith the specified permission, except for thecheckConnect andcheckRead methods thattake a context argument. Those methods expect the context to be anAccessControlContext and they call the context'scheckPermission method with the specifiedpermission.

Method	Permission
public void checkAccept(String host, int port);	java.net.SocketPermission "{host}:{port}", "accept";
public void checkAccess(Thread t);	java.lang.RuntimePermission "modifyThread";
public void checkAccess(ThreadGroup g);	java.lang.RuntimePermission "modifyThreadGroup";
public void checkAwtEventQueueAccess();	java.awt.AWTPermission "accessEventQueue";
public void checkConnect(String host, int port);	if (port == -1) java.net.SocketPermission"{host}","resolve"; else java.net.SocketPermission "{host}:{port}","connect";
public void checkConnect(String host, int port, Objectcontext);	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 "<<ALL_FILES>>","execute";
public void checkExit(int status);	java.lang.RuntimePermission "exitVM.{status}";
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")); }}
public void checkMulticast(InetAddress maddr);	java.net.SocketPermission(maddr.getHostAddress(),"accept,connect");
public void checkMulticast(InetAddress maddr, byte ttl);	java.net.SocketPermission(maddr.getHostAddress(),"accept,connect");
public void checkPackageAccess(String pkg);	java.lang.RuntimePermission "accessClassInPackage.{pkg}";
public void checkPackageDefinition(String pkg);	java.lang.RuntimePermission "defineClassInPackage.{pkg}";
public void checkPrintJobAccess();	java.lang.RuntimePermission "queuePrintJob";
public void checkPropertiesAccess();	java.util.PropertyPermission "*", "read,write";
public void checkPropertyAccess(String key);	java.util.PropertyPermission "{key}", "read,write";
public void checkRead(FileDescriptor fd);	java.lang.RuntimePermission "readFileDescriptor";
public void checkRead(String file);	java.io.FilePermission "{file}", "read";
public void checkRead(String file, Object context);	java.io.FilePermission "{file}", "read";
public void checkSecurityAccess(String action);	java.security.SecurityPermission "{action}";
public void checkSetFactory();	java.lang.RuntimePermission "setFactory";
public void checkSystemClipboardAccess();	java.awt.AWTPermission "accessClipboard";
public boolean checkTopLevelWindow(Object window);	java.awt.AWTPermission "showWindowWithoutWarningBanner";
public void checkWrite(FileDescriptor fd);	java.lang.RuntimePermission "writeFileDescriptor";
public void checkWrite(String file);	java.io.FilePermission "{file}", "write";
public SecurityManager();	java.lang.RuntimePermission "createSecurityManager";

Movatterモバイル変換

Permissions in the Java Development Kit (JDK)

Permission Descriptionsand Risks

AllPermission

SecurityPermission

UnresolvedPermission

AWTPermission

FilePermission

SerializablePermission

ReflectPermission

RuntimePermission

NIO-Related Targets

NetPermission

SocketPermission

SQLPermission

PropertyPermission

LoggingPermission

SSLPermission

AuthPermission

PrivateCredentialPermission

DelegationPermission

ServicePermission

AudioPermission