appa.html

jdbc书

	"readFileDescriptor";
  permission java.lang.RuntimePermission 
	"writeFileDescriptor";
  permission java.lang.RuntimePermission 
	"loadLibrary.<library name>";
  permission java.lang.RuntimePermission 
	"accessClassInPackage.<package name>";
  permission java.lang.RuntimePermission 
	"defineClassInPackage.<package name>";
  permission java.lang.RuntimePermission 
	"accessDeclaredMembers.<class name>";
  permission java.lang.RuntimePermission 
	"queuePrintJob";
};
</PRE>

<FONT FACE="Verdana, Arial, Helvetica, sans-serif">

<P>
The naming convention for target information where a library, 
package, or class name is added follows the hierarchical 
property naming convention, and includes wild cards. An asterisk at 
the end of the target name, after a dot (<CODE>.</CODE>), or alone 
signifies a wild card match.  For example, <CODE>loadLibrary.*</CODE> 
or <CODE>*</CODE> are valid, but
<CODE>*loadLibrary</CODE> or <CODE>a*b</CODE> are not.

<P>
<STRONG>createClassLoader</STRONG>: 
This target grants permission to create a class loader.
Granting this permission might allow a malicious
application to instantiate its own class loader and load
harmful classes into the system. Once loaded, the class loader 
could place these classes into any protection domain and give them full 
permissions for that domain.

<P>
<STRONG>getClassLoader</STRONG>:
This target grants permission to retrieve the class loader for the
calling class.  Granting this permission could enable malicious
code to get the class loader for a particular class and load 
additional classes. 

<P>
<STRONG>setContextClassLoader</STRONG>:
This target grants permission to set the context class loader used by 
a thread. System code and extensions use the context class loader 
to look up resources that might not exist in the system 
class loader. Granting this permission allows
code to change which context class loader is used
for a particular thread, including system threads. This
can cause problems if the context class loader has malicious
code.

<P>
<STRONG>setSecurityManager</STRONG>:
This target grants permission to set or replace the security manager.
The security manager is a class that allows applications to implement a 
security policy. Granting this permission could enable malicious
code to install a less restrictive manager, and thereby, 
bypass checks that would have been enforced by the original security manager.

<P>
<STRONG>createSecurityManager</STRONG>:
This target grants permission to create a new security manager.
Granting this permission could give malicious code access to protected 
and sensitive methods that might
disclose information about other classes or the execution stack.
It could also allow the introduction of a weakened security manager.

<P>
<STRONG>exitVM</STRONG>:
This target grants permission to halt the Java VM.
Granting this permission could allow malicious code to mount
a denial-of-service attack by automatically forcing the VM to
stop.

<P>
<STRONG>setFactory</STRONG>:
This target grants permission to set the socket factory used by
the <CODE>ServerSocket</CODE> or <CODE>Socket</CODE> class, or
the stream handler factory used by the <CODE>URL</CODE> class.
Granting this permission allows code to set the actual 
implementation for the socket, server socket, stream handler, or 
Remote Method Invocation (RMI) socket factory.
An attacker might set a faulty implementation that mangles the data 
stream.

<P>
<STRONG>setIO</STRONG>:
This target grants permission to change the value of the
<CODE>System.out</CODE>, 
<CODE>System.in</CODE>, and <CODE>System.err</CODE> standard
system streams. Granting this permission could allow an attacker
to change <CODE>System.in</CODE> to steal user input, or 
set <CODE>System.err</CODE> to a <CODE>null</CODE> output stream,
which would hide any error messages sent to <CODE>System.err</CODE>. 

<P>
<STRONG>modifyThread</STRONG>:
This target grants permission to modify threads by calls
to the <CODE>stop</CODE>, <CODE>suspend</CODE>, <CODE>resume</CODE>,
<CODE>setPriority</CODE>, and <CODE>setName</CODE> methods in the
<CODE>Thread</CODE> class.
Granting this permission could allow an attacker to start or suspend
any thread in the system.

<P>
<STRONG>stopThread</STRONG>:
This target grants permission to stop threads. Granting this 
permission allows code to stop any thread in
the system provided the code already has permission to access that
thread. Malicious code could corrupt the system by killing existing threads.

<P>
<STRONG>modifyThreadGroup</STRONG>:
This target grants permission to modify threads by calls to the
<CODE>destroy</CODE>, <CODE>resume</CODE>, <CODE>setDaemon</CODE>,
<CODE>setmaxPriority</CODE>, <CODE>stop</CODE>, and <CODE>suspend</CODE>
methods of the <CODE>ThreadGroup</CODE> class.
Granting this permission could allow an attacker to create thread groups and
set their run priority.

<P>
<STRONG>getProtectionDomain</STRONG>
This target grants permission to retrieve the <CODE>ProtectionDomain</CODE>
instance for a class. Granting this permission allows code to obtain
policy information for that 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.

<P>
<STRONG>readFileDescriptor</STRONG>:
This target grants permission to read file descriptors.
Granting this permission allows code to read the particular
file associated with the file descriptor, which is dangerous
if the file contains confidential data.

<P>
<STRONG>writeFileDescriptor</STRONG>:
This target grants permission to write file descriptors.
Granting this permission allows code to write to the file
associated with the descriptor, which is dangerous if the 
file descriptor points to a local file.

<P>
<STRONG>loadLibrary.{library name}</STRONG>:
This target grants permission to dynamically link the specified library.
Granting this permission could be dangerous because the security 
architecture is not designed to and does not extend to native 
code loaded by way of the <CODE>java.lang.System.loadLibrary</CODE> method.

<P>
<STRONG>accessClassInPackage.{package name}</STRONG>
This target grants permission to access the specified package
by way of a class loader's <CODE>loadClass</CODE> method when 
that class loader calls the <CODE>SecurityManager.checkPackageAcesss</CODE> 
method. Granting this permission 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.

<P>
<STRONG>defineClassInPackage.{package name}</STRONG>:
This target grants permission to define classes in the
specified package by way of a class loader's <CODE>defineClass</CODE>
method when that class loader calls 
the <CODE>SecurityManager.checkPackageDefinition</CODE> method.
Granting this permission allows code to define a class in a 
particular package, which can be dangerous because malicious
code with this permission might define rogue classes in
trusted packages like <CODE>java.security</CODE> or <CODE>java.lang</CODE>,
for example.

<P>
<STRONG>accessDeclaredMembers</STRONG>:
This target grants permission to access the declared members of
a class. Granting this permission allows code to query a class for
its public, protected, default (package), and private fields and
methods. Although the code would have
access to the private and protected field and method names, it would not
have access to the private and 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, malicious 
code might invoke any public methods or access public fields
in the class, which  could be dangerous if
the code would normally not be able to invoke those methods or
access the fields  because
it cannot cast the object to the class or interface with those methods
and fields.

<P>
<STRONG>queuePrintJob</STRONG>:
This target grants permission to initiate a print job request.
Granting this permission could allow code to print sensitive
information to a printer or maliciously waste paper.

<A NAME="SecurityPermission"></A>
<H3>SecurityPermission</H3>

<CODE>java.security.SecurityPermission</CODE> 
grants access to various security configuration parameters.
The possible targets are listed by name with no action list.
Security permissions currently apply to methods called
on the following objects:

<UL>
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"><CODE>java.security.Policy</CODE>, which represents the
system security policy for applications.  </FONT>
<P>
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"><CODE>java.security.Security</CODE>, which centralizes
all security properties and common security methods. It
manages providers.</FONT>
<P>  
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"><CODE>java.security.Provider</CODE>, which represetns an
implementation of such things as security algorithms (DSA,
RSA, MD5, or SHA-1) and key generation.  </FONT>
<P>
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"><CODE>java.security.Signer</CODE>, which manages private
keys. Even though, <CODE>Signer</CODE> is deprecated, the
related permissions are available for backwards compatibility. </FONT>
<P> 
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"><CODE>java.security.Identity</CODE>, which manages real-world
objects such as people, companies, or organizations whose
identities can be authenticated using their public keys. </FONT>
</UL>

</FONT>

<PRE>
grant {
  permission java.security.SecurityPermission 
	"getPolicy";
  permission java.security.SecurityPermission 
	"setPolicy";
  permission java.security.SecurityPermission 
	"getProperty.os.name";
  permission java.security.SecurityPermission 
	"setProperty.os.name";
  permission java.security.SecurityPermission 
	"insertProvider.SUN";
  permission java.security.SecurityPermission 
	"removeProvider.SUN";
  permission java.security.SecurityPermission 
	"setSystemScope";
  permission java.security.SecurityPermission 
	"setIdentityPublicKey";
  permission java.security.SecurityPermission 
	"setIdentityInfo";
  permission java.security.SecurityPermission 
	"addIdentityCertificate";
  permission java.security.SecurityPermission 
	"removeIdentityCertificate";
  permission java.security.SecurityPermission 
	"clearProviderProperties.SUN";
  permission java.security.SecurityPermission 
	"putProviderProperty.&#60;provider name&gt;";
  permission java.security.SecurityPermission 
	"removeProviderProperty.SUN";
  permission java.security.SecurityPermission 
	"getSignerPrivateKey";
  permission java.security.SecurityPermission 
	"setSignerKeyPair";
};
</PRE>

<FONT FACE="Verdana, Arial, Helvetica, sans-serif">

<STRONG>getPolicy</STRONG>:
This target grants permission to retrieve the system-wide security
policy. Granting this permission discloses which permissions would be 
granted to a given application or applet.
While revealing the policy does not compromise the security of
the system, it does provide malicious code with additional information
it could use to better aim an attack. 

<P>
<STRONG>setPolicy</STRONG>:
This target grants permission to set the system-wide security
policy. Granting this permission could allow malicious code to 
grant itself all the necessary permissions to successfully mount
an attack an attack on the system.

<P>
<STRONG>getProperty.{key}</STRONG>:
This target grants permission to retrieve the security property
specified by <CODE>{key}</CODE>.
Depending on the particular key for which access has
been granted, the code may have access to the list of security
providers and 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.

<P>
<STRONG>setProperty.{key}</STRONG>:
This target grants permission to set the security property
specified by <CODE>{key}</CODE>.
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.

<P>
<STRONG>insertProvider.{provider name}</STRONG>:
This target grants permission to add the new security provider specified
by <CODE>{provider name}</CODE>. Granting this permission allows
the introduction of a possibly malicious provider that could do
such things as disclose the private keys passed to it. This is possible
because the <CODE>Security</CODE> object, which manages the installed 
providers, does not currently check the integrity or authenticity of a 
provider before attaching it.

<P>
<STRONG>removeProvider.{provider name}</STRONG>:
This target grants permission to remove the provider specified by
<CODE>{provider name}</CODE>. Granting this permission could
change the behavior or disable execution of other
parts of the program. If a provider requested by the
program has been removed, execution might fail. 

<P>
<STRONG>setSystemScope</STRONG>:
This target grants permission to set the system identity scope.
Granting this permission could allow an attacker to configure the system
identity scope with certificates that should not be trusted. This
could grant code signed with those certificates privileges that would
be denied by the original identity scope.

<P>
<STRONG>setIdentityPublicKey</STRONG>:
This target grants permission to set the public key for
an <CODE>Identity</CODE> object. 
If the identity is marked <EM>trusted</EM>, this allows an attacker to 
introduce its own public key that is not trusted
by the system's identity scope.This could grant code signed with that
public key privileges that would be otherwise denied.

<P>
<STRONG>SetIdentityInfo</STRONG>:
This target grants permission to set a general information string
for an <CODE>Identity</CODE> object.
Granting this permission allows attackers to set the general
description for an identity. Doing so could trick applications