How does a JSP page invoke a native application? Like C:/netterm.exe? __js

Sorry, my intention is this: the client executes the program on the client. Runtime.getruntime (). EXEC ("C:/netterm.exe"), written in the JSP on the client, can only start the Netterm.exe on the server.
And I just want to perform the Netterm.exe on the client.

If there are programs in the Control Panel program, available
<input Type=button onclick= "exec (' program. EXE ') "value=" calling program >
If not, you can write the path clearly.
For example, exec ('%java_home%//bin//javac.bat ')

I put your runtime. The code is made into an applet. Digital signatures on the server side, the client did nothing.
This allows you to invoke mine clearance, notebook programs on the client. But by calling media player, there's no response at all.
I use Appletviewer to jump on the server side of this applet, found an exception: Java.security.AccessControlException:access denied (java.io.FilePermission <<al
L files>> execute).
Maybe because I haven't changed the client's policy file, I don't know how to fix it.
What do you have to do to solve this problem?

Using policy to set the Java security Policy

--------------------------------------------------------------------------------

SOURCE Author: Yang Shaofang Popularity: 1723

As we all know, the Java language has a perfect security framework, from programming languages, compilers, interpreters to Java virtual machines, to ensure that the Java system is not corrupted by invalid code or hostile compilers, and basically, they ensure that Java code operates according to predetermined rules. However, when we need to overcome these limitations, such as reading and writing files, listening and writing sockets, exiting the Java system, and so on, you must use digital signatures or security policy files (*. Policy).
In enterprise intranet, this paper proposes a simple method of using security policy file to set permissions of Java programs. Because of the location of the computers in the intranet, use and security are clear, better suited to use security policy files to set up Java permissions, software installation, Setup, upgrades and migrations are very convenient, and, and digital signatures can be used in conjunction with, more importantly, you can subdivide the permissions of each Java program, Flexible and convenient to use.
A. The concept of security policy in Java
The security policy for the Java application environment, detailing the licensing of different resources owned by different code, is expressed by a policy object. In order for the applet (or an application running under SecurityManager) to perform protected behavior, such as reading and writing files, the applet (or Java application) must obtain permission for that operation, and the security policy file is used to implement these licenses.
The policy object may have multiple entities, although at any time only one function can occur. The currently installed policy object can be obtained either by calling the GetPolicy method in the program or by invoking the SetPolicy method. The policy object evaluates the entire policy and returns an appropriate permissions object detailing which code can access those resources.
Policy files can be stored in unformatted ASCII files, or in binary files of policy classes, or in databases. This article discusses only the form of unformatted ASCII files.
Two. Policy file format
To better understand the content below, it is recommended that you refer to the contents of the/jdk1.2/jre/lib/security/java.policy and/jdk1.2/jre/lib/security/java.security files when reading.
1. Syntax format and description of policy file
A policy file is essentially a list of records, which may contain a "keystore" record, and contain 0 or more "grant" records. The format is as follows:
KeyStore "Some_keystore_url", "Keystore_type";
Grant [Signedby "Signer_names"] [, CodeBase "URL"] {
Permission Permission_class_name
["Target_name"] [, "Action"] [, Signedby "Signer_names"];
Permission ...};
1.1 "KeyStore" record
A keystore is a private key database and corresponding digital signature, such as a X.509 certificate. The policy file may have only one keystore record (or it may not contain the record), and it can appear anywhere outside of the grant record in the file. The keystores specified in the policy configuration file is used to find the public key of the signer specified in the grant record, if any grant record specifies the signer (signer_names), The KeyStore record must appear in the policy configuration file.
"Some_keystore_url" refers to the KeyStore URL location, "Keystore_type" refers to the type of KeyStore. The second option is optional, and if not specified, the type is assumed to be determined by the "Keystore.type" property in the Security properties file (java.security). The KeyStore type defines the storage and data format of the KeyStore information, which is used to protect the private key and KeyStore integrity in the KeyStore algorithm. The default type supported by Sun Microsystems is "JKS".
1.2 "Grant" records
Each grant record in the policy file contains a codesource (a specified code) and its permission (license).
Each grant record in the policy file follows the following format, beginning with the reserved word "grant", which represents the beginning of a new record, and "Permission" is another reserved word that marks the beginning of a new license in the record. Each grant record grants a specified code (CodeBase) set of licenses (Permissions).
Permission_class_name must be a qualified and existing class name, such as java.io.FilePermission, and cannot use abbreviations (for example, filepermission).
Target_name is used to specify the location of the target class, and the action is used to specify the permissions that the target class has.
Target_name can directly specify the class name (which can be an absolute or relative path), the directory name, or the following wildcard character:
All files under the directory/* directory
* All files in current directory
All files under the directory/-directory, including subdirectories
-All files in the current directory, including subdirectories
All files in the All Files file system
For Java.io.filepermission,action can be:
Read, write, delete, and execute.
For Java.net.socketpermission,action can be:
Listen,accept,connect,read,write.
Attribute extensions in 1.3 Policy files (property expansion)
The property extension is similar to the variable extension used in the shell, which is in the following format:
"${some.property}"
Examples of actual use are:
Permission Java.io.FilePermission "${user.home}", "read"; The value of ' ${user.home} ' is ' D:/project ',
Therefore, the following statement is the same as the preceding statement:
Permission Java.io.FilePermission "D:/project", "read";
Three. Examples
When policy is initialized, the system policy is loaded first, then the user policy is added, and if neither exists, the default policy, the original sandbox model, is used.
The default location for system policy files is:
{Java.home}/lib/security/java.policy (Solaris)
{Java.home}/lib/security/java.policy (Windows)
The default location for user policy files is:
{User.home}/.java.policy (Solaris)
{User.home}/.java.policy (Windows)
In fact, in practice, we may not be as complex as described above, especially when you are not using digital signatures. At this point, we can learn from JDK 1.2 to provide us with the ready-made/jdk1.2/jre/lib/security/java.policy files, according to our needs to make the appropriate changes, this article on the use of digital signatures in detail to describe the use of security policy files.
Below, is a complete. java.policy file that is used under Windows 95/98/nt. The purpose of each "permission" record is illustrated in the file, using the form of annotations, respectively.
For Lanservertalk.java and Lanclienttalk.java
Grant {
"Read" Permissions on system and user directories
Permission Java.util.PropertyPermission "User.dir", "read";
Permission Java.util.PropertyPermission "User.home", "read";
Permission Java.util.PropertyPermission "Java.home", "read";
Permission Java.util.PropertyPermission "Java.class.path", "read";
Permission Java.util.PropertyPermission "User.Name", "read";
Operating permissions on threads and thread groups
Permission Java.lang.RuntimePermission "Modifythread";
Permission Java.lang.RuntimePermission "Modifythreadgroup";
Various permissions to manipulate the socket port
Permission Java.net.SocketPermission "-", "Listen";
Permission Java.net.SocketPermission "-", "accept";
Permission Java.net.SocketPermission "-", "Connect";
Permission Java.net.SocketPermission "-", "read";
Permission Java.net.SocketPermission "-", "write";
Permission to read and write files
Permission Java.io.FilePermission "-", "read";
Permission Java.io.FilePermission "-", "write";
Permissions to exit the system, such as System.exit (0)
Permission Java.lang.RuntimePermission "EXITVM";
};
Four. Use of Java.policy documents
For Windows 95/98/nt, there are two main ways to use. java.policy files.
1. Use default directory
We can simply copy the edited. java.policy file to the Windows 95/98/nt home directory, at which point all applets (or Java applications) may have some of the same permissions, simple to use, But not flexible (for example: for Java.io.FilePermission, its target class target_name must use absolute path), if not used in the enterprise intranet, there may be some security risks.
2. Specified on the command line
At the command line, if we want to pass a policy file to Appletviewer, you can also use the "-j-djava.security.policy" parameter to specify the location of the policy:
Appletviewer-j-djava.security.
Policy=purl MyApplet
Purl is the location of the policy file. The following is a practical example of running the current directory lanservertalk.html (loading and running Lanservertalk.java) in the security policy specified by the current directory's. java.policy file:
Appletviewer-j-djava.security.policy
=.java.policy lanservertalk.html
This method is flexible to use, especially as a software package when publishing in an intranet, installing, setting up, and migrating it, without having to modify the contents of the policy file, it is fairly simple to use, and the scope of the security license is controlled more finely.