Java JVM Learning Note 10 (Policy and protection domains)

Welcome reprint Please indicate Source: http://blog.csdn.net/yfqnihao/article/details/8271415

In the previous section, we did a simple experiment to illustrate what a strategy file is, at the end of the article, and incidentally, what is the strategy and the role of the strategy.

To elicit another very important concept Protectiondomain (protection domain), let's review what is a strategy first .

First of all, what is a strategy, today's things are purely comparative concepts. Of course, if you've read note nine, today's stuff, it's really soso

Policy and Policy files:

Java's access control policy for an application is represented by a singleton of a subclass of the abstract class Java.security.Policy, and at any time, each application actually has only one policy object, which corresponds to the policy file . The class loader uses this policy object to help them decide what permissions should be granted when importing a piece of code into a virtual machine.

The words above tell us an application corresponds to a policy object, and a policy object corresponds to a policy file.

So the policy file, in addition to our note nine in a folder under the limit of all the files can also play a role in what subject? Let's take a look at the following policy file MyPolicy.txt

KeyStore "Ijvmkeys""friend" {       "d:/testpolicy.txt", "Read,write";   " Stranger " {       " d:/testpolicy.txt "," Read,write ";   };  " file:d:/workspace/testpolicy/bin/* " {       " d:/testpolicy.txt "," Read,write ";   

A simple explanation

The first line: KeyStore "Ijvmkeys", the meaning of this line, the key pair is stored in the current directory of a file called Ijvmkeys (remember that note eight did the Jar package signature experiment)

The second line: Grant Signedby "friend", Grant is authorized, this line means to give a "friend" key to the signature of the file authorization

The third line: Permission Java.io.FilePermission "D:/testpolicy.txt", "read,write"; this line means to grant permission to read and write to D:/testpolicy.txt

Last line: Grant CodeBase "file:d:/workspace/testpolicy/bin/*" The sentence we saw in note nine, that is, to d:/workspace/testpolicy/bin/* Permissions are granted to all files under the

Point one: Here we should be able to know that the policy file can be authorized for a series of signed Code libraries ("friend", "Stranger" is a code base ) or to a source of code ( A specific path, or URL, is a code source) authorization.

Key two: Policy files can not only be stored in the file (what is the suffix name is not important), but also can be stored in the database.

Here we have a more complete concept of the strategy, but you have no such a doubt, before we always say, an application corresponding to a policy single case, a policy single case corresponding to a policy file, how exactly does it correspond? Let's take a look at it below.

Before we explore, we first introduce a new concept called the Protection Domain (Protectiondomain), in note three, we mentioned that the class loader will put a class file load memory when it will be placed in a protection domain , is drip today I say what is protect the domain.

What is a protection domain

When class loaders load types into a Java virtual machine, they assign a protection domain to each type. A protection domain defines all the permissions granted to a particular code. (A protection domain corresponds to one or more grant clauses in the policy file.) Each type that is loaded into a Java virtual machine belongs to one and belongs to only one protection domain.

The class loader knows the codebase and signer of all classes or interfaces it loads. It uses this information to create a Codesource object. It passes this Codesource object to the GetPermissions () method of the current policy object to get the subclass instance of this abstract class java.security.PermissionCollection. This permissincollection contains references to all permission objects (these permission objects are granted the specified code source by the current policy). It can instantiate a new Protectdomain object using the Codesource it creates and the permissioncollection it gets from the policy object. It puts the code into a protection domain by passing the appropriate Protectiondomain object to the DefineClass () method.

If you can't understand the above, look at the figure below

Well, after reading the whole process above, do you already understand what the protection domain is.

Now let's tidy up the contents of today, a little more concept, one by one.

Codesource: code Source, this is an object generated by the class loader Java.security.CodeSource, ClassLoader by reading the class file, the jar package knows who signed the class name (can have more than one signer , for signatures, see notes Seven and VIII) and encapsulate the signers member assigned to the Codesource object by a signer array, through the source of this class (possibly from a local URL or a network ur, corresponding to the grant note JIU Li Mypollicy " Friend "or FILE::....L) to the location member of Codesource, and the public key certificate of this class is assigned to the Certs member of Codesource (usually a jar can be guaranteed by multiple groups or institutions, that is, we say authentication, The java1.2 default security manager also has an access control architecture that can only work on the certificate, not the bare public key, and in fact, when we generate a key pair with Keytool, a self-signed certificate is generated, so the keytool generated key pair is not naked. If you have questions, let's look at the code in the JDK

 Public classCodesourceImplementsjava.io.Serializable {Private Static Final LongSerialversionuid = 4977541819976013951L; /*** the code location. *     * @serial     */    PrivateURL location;//Local code base    /** The code signers. */    Private transientCodesigner[] Signers =NULL;//signer    /** The code signers.     Certificate chains is concatenated. */    Private transientJava.security.cert.Certificate certs[] =NULL;//Certificate

Policy : The strategy is a singleton object used to read the policy file through the incoming Codesource object (since the Codesource object contains the signer and the source of the code) so he reads the grant segment, Remove the Perssiom and return a perssiomcollection. There is a very important member variable in this class.

    // Cache Mapping  Protectiondomain to PermissionCollection    private weakhashmap pdmapping;

Why this member is important, let's look at a way

    Private Static void Initpolicy (final  Policy p) {              ...           if NULL ) {          .......         synchronized (p.pdmapping) {        //  cache of PD to permissions        p.pdmapping.put ( Policydomain, policyperms);        }    }     return ;    }

We mainly look at the key code. The pdmapping is to use the protection domain object as a key to present the permission set as value in the map. So we say a protection domain corresponds to the permission of the GRANT clause for multiple policy files.

Protectiondomain: The protection domain, which we have already introduced, is used to hold the class file, and a Perssiom,codesource object, if you have any questions about it, we also look at its code, To verify our conclusions.

 Public classProtectiondomain {/*Codesource*/    PrivateCodesource Codesource;//Code Source    /*ClassLoader The protection domain was consed from*/    PrivateClassLoader ClassLoader;//class Loader    /*Principals Running-as within this protection domain*/    Privateprincipal[] Principals; /*The rights This protection domain is granted*/    PrivatePermissionCollection permissions;//Permissions Collection

Permission: Permission, which corresponds to a Permission in the GRANT clause of our note JIU Li, has a simple structure, a permission name and an action, As if our note Jiu Li's java.io.FilePermission is a permission name

While the action is read and write, it corresponds to a string in permission.

Now let's use a picture to concatenate the above concepts.

Here we have a more complete idea, from note four to this section of note 10, all we have to say is only one thing, the class loader when loading the class (or the execution Class) will call the security Manager, security Manager, then through the decision of the policy to determine whether we are allowed to load this class, or do some operations , allowing a file to read and write (which we have already experimented with in note nine). So, do you have any questions about how the security manager is going to invoke the policy? Here we have to present a new concept to access the controller AccessControl, if you want to know what the access controller is doing, what to do, how to work with security management, then please read the next section.

Java JVM Learning Note 10 (Policy and protection domains)