Something about SecurityManager

The Java Security was made up of ClassLoader, Class file inspection, built-in security and securityManager.
The built-in security includes safely type cast, structural memory access, GC, bound check of array, null reference check.
The first three parts can ensure the integrity of the running program and JVM instance. However, SecurityManager attempts to protect the outer resource from being attacked by millions lines of code.
When a program starts, it will point to a java.lang.SecurityManager or pass its subtype's instance to setSecurityManager method as a parameter to install the SecurityManager. If it doesn't do so, the Java API can do anything without any restriction. Before the version 1.2, java.lang.SecurityManager was an abstract class and now it is a concrete class supplying a default implementation.
SecurityManager permits users to define policies without coding only by defining a file named policy file (ASIIC file). The permission is defined as a class extending from java.security.Permission, such as java.io.FilePermission to grant reading, writing, and executing permissions. When a SecurityManager is created, it will parse the policy file and generate the CodeSource and Permission Objects, which are encapsulated in a single Policy Object representing a runtime policy. Anytime there will be only one Policy installed Object.

 When the check methods of a SecurityManager are called, many of them will pass the requests to an AccessControl Class. There are 28 different check methods in the old version and there are two another methods added into the version after 1.2, which are checkPermission(Permission) and checkPermission(Permission,Object).

 

Here is an example of one policy file called policy.txt

keystore "ijvmkeys";

grant signedBy "friend" {
    permission java.io.FilePermission "question.txt", "read";
    permission java.io.FilePermission "answer.txt", "read";
};

grant signedBy "stranger" {
    permission java.io.FilePermission "question.txt", "read";
};

grant codeBase "file :${com.artima.ijvm.cdrom.home}/security/ex2/-" {
 permission java.io.FilePermission "question.txt", "read";
 permission java.io.FilePermission "answer.txt", "read";
};

 

It points out that if you use a jar package signed by "friend", you can read two files - question.txt and answer.txt; otherwise if you are "stranger", you can only read the question.txt.

The third segment means the policy file grants a read permission to the class file whose location is under the ${com.artima.ijvm.cdrom.home}/security/ex2/

 

The original article was edited by the blogger for correcting several grammar mistakes.

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/liuxizhiyi/archive/2008/10/23/3129893.aspx