|CONTENTS | PREV | NEXT|
A security manager is not automatically installed when an application is running. To apply the same security policy to an application found on the local file system as to downloaded applets, either the user running the application must invoke the Java Virtual Machine with the new "-Djava.security.manager" command-line argument (which sets the value of the java.security.manager property), as in
java -Djava.security.manager SomeAppor the application itself must call the
setSecurityManagermethod in the java.lang.System class to install a security manager.
It is possible to specify on the command line a particular security manager to be utilized, by following "-Djava.security.manager" with an equals and the name of the class to be used as the security manager, as in
java -Djava.security.manager=COM.abc.MySecMgr SomeAppIf no security manager is specified, the built-in default security manager is utilized (unless the application installs a different security manager). All of the following are equivalent and result in usage of the default security manager:
java -Djava.security.manager SomeApp java -Djava.security.manager="" SomeApp java -Djava.security.manager=default SomeAppJava 2 SDK includes a property named java.class.path. Classes that are stored on the local file system but should not be treated as base classes (e.g., classes built into the SDK) should be on this path. Classes on this path are loaded with a secure class loader and are thus subjected to the security policy being enforced.
There is also a "-Djava.security.policy" command-line argument whose usage determines what policy files are utilized. This command-line argument is described in detail in the "Default System and User Policy Files" section. Basically, if you don't include "-Djava.security.policy" on the command line, then the policy files specified in the security properties file will be used.
You can use a "-Djava.security.policy" command-line argument to specify an additional or a different policy file when invoking execution of an application. For example, if you type the following, where pURL is a URL specifying the location of a policy file, then the specified policy file will be loaded in addition to all the policy files specified in the security properties file:
java -Djava.security.manager -Djava.security.policy=pURL SomeAppIf you instead type the following command, using a double equals, then just the specified policy file will be used; all others will be ignored:
java -Djava.security.manager -Djava.security.policy==pURL SomeApp
checkmethods in SecurityManager are still supported, although most of their implementations are changed to call the new SecurityManager
checkPermissionmethod, whose default implementation calls the AccessController
checkPermissionmethod. Note that certain internal security checks may stay in the SecurityManager class, unless it can be parameterized.
We have not at this time revised
any system code to call AccessController instead of calling
SecurityManager (and checking for the existence of a classloader),
because of the potential of existing third-party applications that
subclass the SecurityManager and customize the
methods. In fact, we added a new method
SecurityManager.checkPermission that by default simply
To understand the relationship
between SecurityManager and AccessController, it is sufficient to
note that SecurityManager represents the concept of a central point
of access control, while AccessController implements a particular
access control algorithm, with special features such as the
doPrivileged method. By keeping SecurityManager up to
date, we maintain backward compatibility (e.g., for those
applications that have written their own security manager classes
based on earlier versions of the JDK) and flexibility (e.g., for
someone wanting to customize the security model to implement
mandatory access control or multilevel security). By providing
AccessController, we build in the algorithm that we believe is the
most restrictive and that relieves the typical programmer from the
burden of having to write extensive security code in most
We encourage the use of AccessController in application code, while customization of a security manager (via subclassing) should be the last resort and should be done with extreme care. Moreover, a customized security manager, such as one that always checks the time of the day before invoking standard security checks, could and should utilize the algorithm provided by AccessController whenever appropriate.
/docs/technotes/tools/windowssubdirectories of the SDK release directory (where the directory separators are actually "\" on Windows systems).
/j2sdk1.2/docs/tooldocs/solaris/keytool.html /j2sdk1.2/docs/tooldocs/windows/keytool.htmlIf the Java 2 SDK is installed in a directory named "C:\j2sdk1.2" on a Windows system, then the keytool documentation for Solaris and Windows users, respectively, can be found in
The chains of X.509 certificates are provided by organizations called Certification Authorities, or CAs. Identities (including CAs) use their private keys to authenticate their association with objects (such as with channels which are secured using SSL), with archives of code they signed, or (for CAs) with X.509 certificates they have issued. As a bootstrapping tool, certificates generated using the -genkey command may be used until a Certification Authority returns a certificate chain.
The private keys in this database are always stored in encrypted form, to make it difficult to disclose these private keys inappropriately. A password is required to access or modify the database. These private keys are encrypted using the "password", which should be several words long. If the password is lost, those authentication keys cannot be recovered.
This tool is (currently) intended to be used from the command line, where one simply types "keytool" as a shell prompt. keytool is a script that executes the appropriate Java classes and is built together with the SDK.
The command line options for each command may be provided in any order. Typing an incorrect option or typing "keytool -help" will cause the tool's usage to be summarized on the output device (such as a shell window), as given below.
% keytool -help KeyTool usage: -certreq [-v] [-alias <alias>] [-sigalg <sigalg>] [-file <certreq_file>] [-keypass <keypass>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -delete [-v] -alias <alias> [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -export [-v] [rfc] [-alias <alias>] [-file <cert_file>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -genkey [-v] [-alias <alias>] [-keyalg <keyalg>] [-keysize <keysize>] [-sigalg <sigalg>] [-dname <distinguished_name>] [-validity <valDays>] [-keypass <keypass>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -help -identitydb [-v] [-file <idb_file>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -import [-v] [-noprompt] [-alias <alias>] [-file <cert_file>] [-keypass <keypass>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -keyclone [-v] [-alias <alias>] -dest <dest_alias> [-keypass <keypass>] [-new <new_keypass>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -keypasswd [-v] [-alias <alias>] [-keypass <old_keypass>] [-new <new_keypass>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -list [-v | -rfc] [-alias <alias>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -printcert [-v] [-file <cert_file>] -selfcert [-v] [-alias <alias>] [-sigalg <sigalg>] [-dname <distinguished_name>] [-validity <valDays>] [-keypass <keypass>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>] -storepasswd [-v] [-new <new_storepass>] [-keystore <keystore>] [-storepass <storepass>] [-storetype <i>storetype</i>]
policytool. This again is a script built with the SDK that invokes the appropriate (non-public) implementation classes.
/docs/technotes/tools/windows/directory in the directory in which the SDK was installed (where the file separators are actually backslashes on Windows systems).
% jarsigner Usage: jarsigner [options] jar-file alias jarsigner -verify [options] jar-file [-keystore <url>] keystore file location [-storepass <password>] password for keystore integrity [-keypass <password>] password for private key (if different) [-sigfile <file>] name of .SF/.DSA file [-signedjar <file>] name of signed JAR file [-verify] verify a signed JAR file [-verbose] verbose output when signing/verifying [-certs] display certificates when verbose and verifying [-internalsf] include .SF file inside signature block [-sectionsonly] don't compute hash of entire manifestAgain, this tool is a script built with the SDK. Note that it is expected that this tool and the existing jar tool script may be merged in the near future to form a single command-line primitive to create JARs, either signed or unsigned.