appa.html

jdbc书

who want to write their own security manager to customize
the verifications and approvals needed in a program.

<P>
Here is a short example to show you how to translate the first
couple of lines in a stack trace to a policy file entry. The first 
line tells you access is denied. This means this stack trace was 
generated because the program tried to access a system resource 
without the proper permission. The second line means you need a 
<CODE>java.net.SocketPermission</CODE> that gives the program 
permission to <CODE>connect</CODE> to and <CODE>resolve</CODE>
the host name for Internet Protocol (IP) address 129.144.176.176, 
port 1521.

</FONT>

<PRE>
java.security.AccessControlException: access denied 
     (java.net.SocketPermission 
     129.144.176.176:1521 connect,resolve)
</PRE>

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

To turn this into a policy file entry, list the permission name,
a target, and an action list as follows where 
<CODE>java.net.SocketPermission</CODE> is the permission name,
<CODE>129.144.176.176:1521</CODE> is the target, and
<CODE>connect,resolve</CODE> is the action list.

</FONT>

<PRE>
grant {
  permission java.net.SocketPermission 
  "129.144.176.176:1521", "connect,resolve";
};
</PRE>

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

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

<CODE>java.security.AllPermission</CODE> specifies all permissions
in the system for all possible targets and actions.
This permission should be used only during testing because it
grants permission to run with all security restrictions disabled
as if there were no security manager.

</FONT>

<PRE>
grant {
  permission java.security.AllPermission;
};
</PRE>

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

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

<CODE>java.awt.AWTPermission</CODE> grants
access to the following Abstract Window Toolkit (AWT) targets.
The possible targets are listed by name with no action list.

</FONT><PRE>
grant {
  permission java.awt.AWTPermission 
		"accessClipboard";
  permission java.awt.AWTPermission 
		"accessEventQueue";
  permission java.awt.AWTPermission 
		"showWindowWithoutWarningBanner";
};
</PRE>

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

<STRONG>accessClipboard</STRONG>: 
This target grants permission to post information to and retrieve 
information from the AWT clipboard. Granting this permission
could allow malicious code to share potentially sensitive or
confidential information.

<P>
<STRONG>accessEventQueue</STRONG>:
This target grants permission to access the AWT event queue.
Granting this permission could allow malicious code to
peek at and remove existing events from the system, or post bogus
events that could cause the application or applet to perform
malicious actions.

<P>
<STRONG>listenToAllAWTEvents</STRONG>:
This target grants permission to listen to all AWT events
throughout the system. Granting this permission could allow
malicious code to read and exploit confidential user input 
such as passwords. 

<P>
Each AWT event listener is called from within the context of 
that event queue's <CODE>EventDispatchThread</CODE>, so if the 
<CODE>accessEventQueue</CODE> permission is also enabled, malicious 
code could modify the contents of AWT event queues throughout the 
system, which can cause the application or applet to perform 
unintended and malicious actions.

<P>
<STRONG>readDisplayPixels</STRONG>:
This target grants permission to read pixels back from the
display screen. Granting this permission could allow
interfaces such as <CODE>java.awt.Composite</CODE> that
allow arbitrary code to examine pixels on the display to
include malicious code that snoops on user activities.

<P>
<STRONG>showWindowWithoutWarningBanner</STRONG>:
This target grants permission to display a window without also displaying 
a banner warning that the window was created by an applet.  Without this 
warning, an applet might pop up windows without the user knowing they
belong to an applet. This could be a problem in environments where
users make security-sensitive decisions based on whether the window belongs to 
an applet or an application. For example, disabling the banner warning might 
trick the end user into entering sensitive user name
and password information.

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

<CODE>java.io.FilePermission</CODE> grants access to a 
file or directory. The targets consist of the target pathname and
a comma-separated list of actions.

<P>
This policy file grants read, write, delete, and execute
permission to all files.

</FONT>

<PRE>
grant {
  permission java.io.FilePermission 
	"&lt;&lt;ALL FILES&gt;&gt;", "read, write, delete, execute";
};
</PRE>

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

This policy file grants read and write permission to <CODE>text.txt</CODE>
in the user's home directory.

</FONT>
<PRE>
grant {
  permission java.io.FilePermission 
	"${user.home}/text.txt", "read, write";
};
</PRE>

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

You can use the following wild cards to specify the target
pathname.

<UL>
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif">A pathname that ends in <CODE>/*</CODE>, where <CODE>/*</CODE> is
the file separator character indicates
a directory and all the files contained in that directory. </FONT>

<P>
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif">A pathname that ends with <CODE>/-</CODE> indicates a directory, and 
recursively, all files and subdirectories contained in that directory. </FONT>

<P>
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif">A pathname consisting of a single asterisk (<CODE>*</CODE>) 
indicates all files in the current directory. </FONT>

<P>
<LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif">A pathname consisting of a single dash (<CODE>-</CODE>) 
indicates all files in the current directory, and recursively, all files 
and subdirectories contained in the current directory.</FONT>
</UL>

The actions are specified in a list of comma-separated 
keywords and have the following meanings: 

<UL> 
   <LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> read: Permission to read a file or directory.</FONT>
   <LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> write: Permission to write to and create a file or directory.</FONT>
   <LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> execute: Permission to execute a file or search a directory. </FONT>
   <LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> delete: Permission to delete a file or directory. </FONT>
</UL>

<P>
When granting file permissions, always think about the implications 
of granting read and especially write access to various files and 
directories. The <CODE>&lt;&lt;ALL FILES&gt;&gt;</CODE> permission with write 
action is especially dangerous because it grants permission to write to the 
entire file system. This means the system binary can be replaced, which
includes the Java<A HREF="#TJVM"><SUP>1</SUP></A> Virtual Machine (VM) runtime environment.

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

<CODE>java.net.NetPermission</CODE> grants access to various
network targets. The possible targets are listed by name with no action list. 

</FONT>

<PRE>
grant {
  permission java.net.NetPermission 
	"setDefaultAuthenticator";
  permission java.net.NetPermission 
	"requestPasswordAuthentication";
};
</PRE>

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

<STRONG>setDefaultAuthenticator</STRONG>:
This target grants permission to set the
way authentication information is retrieved when
a proxy or HTTP server asks for authentication. Granting this permission
could mean malicious code can set an authenticator that monitors and
steals user authentication input as it retrieves the input from the user.

<P>
<STRONG>requestPasswordAuthentication</STRONG>:
This target grants permission to ask the authenticator registered with
the system for a password. Granting this permission could mean malicious code
might steal the password.

<P>
<STRONG>specifyStreamHandler</STRONG>:
This target grants permission to specify a stream handler when constructing a 
Uniform Resource Locator (URL). Granting this permission could mean malicious 
code might create a URL with resources to which it would not normally have 
access, or specify a stream handler that gets the actual bytes from 
somewhere to which it does 
have access. This means the malicious code could trick the system into
creating a ProtectionDomain/CodeSource for a class even though
the class really did not come from that location.

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

<CODE>java.util.PropertyPermission</CODE> grants access to
system properties. The <CODE>java.util.Properties</CODE> class
represents persistent settings such as the location of
the installation directory, the user name, or the
user's home directory.  

</FONT>

<PRE>
grant {
  permission java.util.PropertyPermission 
	"java.home", "read";
  permission java.util.PropertyPermission 
	"os.name", "write";
  permission java.util.PropertyPermission 
	"user.name", "read, write";
};
</PRE>

<FONT FACE="Verdana, Arial, Helvetica, sans-serif">
The target list contains the name of the property;
for example, <CODE>java.home</CODE> or  <CODE>os.name</CODE>. 
The naming convention for the properties follows the hierarchical 
property naming convention, and includes wild cards.  An asterisk 
at the end of the property name, after a dot (<CODE>.</CODE>), or alone
signifies a wild card match. For example, <CODE>java.*</CODE> or
<CODE>*</CODE> are valid, but <CODE>*java</CODE> or 
<CODE>a*b</CODE> are invalid.

<P>
The actions are specified in a list of comma-separated keywords,
and have the following meanings:  

<UL> 
   <LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> read: Permission to read (get) a property. </FONT>
   <LI><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> write: Permission to write (set) a property. </FONT>
</UL>

Granting property permissions can leave your system open
to intrusion.  For example, granting permission to access the 
<CODE>java.home</CODE> property makes the 
installation directory vulnerable to attack, and granting permission 
to access the <CODE>user.name</CODE> and <CODE>user.home</CODE> properties 
might reveal the user's account name and home directory to code that might
misuse the informaiton.

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

<CODE>java.lang.reflect.ReflectPermission</CODE> grants
permission for various reflective operations. The possible targets
are listed by name with no action list. 

</FONT>

<PRE>
grant {
  permission java.lang.reflect.ReflectPermission 
	"suppressAccessChecks";
};
</PRE>

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

<STRONG>suppressAccessChecks</STRONG>:
This target grants permission to access fields and invoke methods in a class. 
This includes public, protected, and private fields and methods.
Granting this permission could reveal confidential
information and make normally unavailable methods accessible to
malicious code.

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

<code>java.lang.RuntimePermission</code> 
grants access to various runtime targets such as the
class loader, Java VM, and thread. The possible targets
are listed by name with no action list. 

</FONT>

<PRE>
grant {
  permission java.lang.RuntimePermission 
	"createClassLoader";
  permission java.lang.RuntimePermission 
	"getClassLoader";
  permission java.lang.RuntimePermission 
	"exitVM";
  permission java.lang.RuntimePermission 
	"setFactory";
  permission java.lang.RuntimePermission 
	"setIO";
  permission java.lang.RuntimePermission 
	"modifyThread";
  permission java.lang.RuntimePermission 
	"modifyThreadGroup";
  permission java.lang.RuntimePermission 
	"getProtectionDomain";
  permission java.lang.RuntimePermission 
	"setProtectionDomain";
  permission java.lang.RuntimePermission