Shulou(Shulou.com)06/03 Report--

How to talk about Java access control mechanism? in view of this problem, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

The principle of Java access control mechanism is that some predefined code in some policy configuration files has certain operation permissions on certain resources, and when some code accesses a resource with a certain permission, access is prohibited if the permission is not in the prespecified permission for the resource, otherwise it can be accessed.

The above paragraph is rather obscure to read. Let's take database users and data tables as examples.

Specify that some code has certain operation permissions on certain resources

Some code: user Admin, X

Some resources: database table User

Operation permissions: user Admin (some code) has CRUD permissions on the User table (some resources)

User X (some code) has R permissions on the User table (some resources)

Some code accesses a resource with a certain permission

User X (some code) queries (a permission) the User table (some resources). Because user X has query permissions on the User table in the predefinition, the check passed.

User X (some code) deletes (a permission) a piece of data in the User table (some resources). Because user X in the predefinition only has query permission for the User table and does not have delete permission, the check failed.

The same is true in Java, except that a class in Java is equivalent to a user above, such as ClassA is equivalent to user Admin, and ClassB is equivalent to user X. But in Java, the situation is a little more complicated, for example, ClassB can call the method of ClassA, so at this time, how will the permissions be checked? Let's give an example to illustrate.

Specify that some code has certain operation permissions on certain resources

Some code: user ClassA, ClassB

Some resources: a profile x.properties

Operation permissions: ClassA (some code) has read and write access to x.properties (certain resources)

ClassB (some code) has read access to x.properties (certain resources)

Some code accesses a resource with a certain permission

ClassA (some code) read or write (a permission) configuration file x.properties (some resources), because the predefined ClassA has read and write permissions to x.properties, so the check passed

ClassB (some code) read (a permission) configuration file x.properties (some resources), because the predefined ClassB has read permission to x.properties, so the check passed

ClassB (some code) write (a permission) configuration file x.properties (some resources), because the predefined ClassB does not have write permission to x.properties, so the check failed.

Class B calls ClassA's method of writing x.properties files. What is the checking process?

In Java, no matter how many classes are called repeatedly, they end up operating a resource with a certain permission. For example, here Class B calls ClassA, and its final operation permission is to manipulate the x.properties file with write permission. Then Java will check all the classes during repeated calls to see if they have write permission to the x.properties file, and if so, pass, as long as any class does not have that permission, it will not pass.

The checking process and the calling process are inverse to each other. For example, in the above example, ClassB calls ClassA to write the x.properties file, then JVM will first check whether ClassA has write permission to the x.properties file, because it is in the predefinition, so ClassA is passed. Next, check the ClassB. In the predefinition, ClassB does not have write permission to the x.properties file, so the check fails, and this operation fails.

In the Java access control mechanism, there are mainly the following classes:

SecurityManager

AccessController

AccessControlContext

ProtectionDomain

PermissionCollection

Permission

Policy

SecurityManager/ AccessController

Entry class for access control. In Java, access control is off by default.

AccessControlContext

The calling procedure context of the class. It saves the calling process of the class in the form of a stack. For example, in the above example, if ClassB calls ClassA, then the bottom of the AccessControlContext stack is ClassB, and the top of the stack is ClassA. If ClassA calls ClassC again, then ClassC is pushing the stack, and the top of the stack becomes ClassC.

ProtectionDomain

This is a key class. It defines "some code has certain permissions on certain resources", that is, what permissions the code in that directory has on those resources. It has three properties:

Some code

Generally, it refers to all the code in a directory. For example, "JRE_HOEM/lib/ext" is expressed as CodeBase in Java.

Some resources

For example, a file under the conf directory is represented as a file (folder) path BasePath in Java.

Certain permissions

It refers to the collection of permissions that some code has on certain resources, such as read permissions and write permissions, which are represented as PermissionCollection classes in Java.

PermissionCollection

A collection class for permissions. For example, a collection of file read permissions and file write permissions:

FilePermission (file,SecurityConstants.FILE_WRITE_ACTION)

FilePermission (file,SecurityConstants.FILE_READ_ACTION)

Permission

Some specific permission. For example, file read permission FilePermission (file,SecurityConstants.FILE_WRITE_ACTION)

Policy

Policies that specify that some code has certain permissions on certain resources are defined in the policy file, and Policy is responsible for reading these policies from the configuration file and building the ProtectionDomain based on the policy file. There is only one Policy object in JVM.

The establishment process of "some code has certain operation permissions on certain resources"

In Java, each class has a reference to ProtectionDomain because each class belongs to a specific directory, so you can know what permissions a class has on certain resources. Let's take a look at the process by which each class establishes a relationship with ProtectionDomain:

When ClassLoader loads a class, it encapsulates the class and the set of permissions granted to the class into "java.security.ProtectionDomain", where these permissions are assigned through the ClassLoader and based on the policy file.

1) find the loaded URL of class bytecode

2) if the class is loaded from the package java.*, associate the class with the internal System ProtectionDomain, where System ProtectionDomain has full AllPermission. If the class is not loaded from the package java.*, continue

3) if the ProtectionDomain to be associated with the class exists, you can simply add the reference relationship between them, otherwise continue

4) create a CodeSource object that encapsulates the loading path of class bytecode

5) create a PermissionCollection object and encapsulate the permissions assigned to CodeSource in the policy file into the PC object

6) create a ProtectionDomain that encapsulates CodeSource and PermissionCollection objects, that is, what permissions the code has on those resources: ProtectionDomain = new ProtectionDomain (CodeSource,PermissionCollection)

7) associate the newly loaded class class with the current ProtectionDomain

The reference invocation relationship between the various classes is not described here, let's continue with the example:

Now suppose you have the following code: ${user.dir} / testA/ClassA ${user.dir} / testB/ClassB

The following resources are available: ${user.dir} / conf/x.properties

Add the following policies to the Java policy file:

Grant codeBase "file:$ {user.dir} / testA/*" {

Permission java.io.FilePermission "${user.dir} / conf *", "read"

Permission java.io.FilePermission "${user.dir} / conf *", "write"

}

Grant codeBase "file:$ {user.dir} / testB/*" {

Permission java.io.FilePermission "${user.dir} / conf *", "read"

}

As mentioned above, every Class in Java holds a reference to ProtectionDomain, where the ProtectionDomain models of ClassA and ClassB are as follows:

Suppose that ClassB calls ClassA to write the x.poperties file, then the corresponding model of AccessControlContext and PermissionCollection looks like this:

When AccessController.checkPermission starts to check permissions, it knows that the permissions to be checked this time are FilePermission ("x.properties", "write"), that is, write permissions to "x.properties". So it first gets the ProtectedDomain of all the classes in the calling procedure context (main (JVM)-> ClassB-- > ClassA-- > FileOutputStream-- > AccessController) to find out:

JVM is executed from mian, and its ProtectedDomain is SystemDomain

ClassA's ProtectedDomain is ProtectedDomainA.

ClassB's ProtectedDomain is ProtectedDomainB.

The ProtectedDomain of FileInputStream and AccessController is SystemDomain

After finding out all the ProtectedDomain of the access context, check whether each ProtectedDomain has FilePermission ("x.properties", "write") permission one by one. Because in the Java access control mechanism, it needs to ensure that each called class has this permission to pass the check.

So, start doing the following checks:

1) AccessController-- > SystemDomain: Java internal code protects the domain and has all operation permissions. Check and pass

2) FileInputStream-- > SystemDomain: Java internal code protects the domain and has all operation permissions. Check and pass

3) ClassA-- > ProtectedDomainA: in the above ProtectedDomainA model, we know that it has the permission of FilePermission ("x.properties", "write"). The check passed.

4) ClassB-- > ProtectedDomainB: in the above ProtectedDomainB model, we know that it does not have FilePermission ("x.properties", "write") permission, and the check fails.

This is the answer to the question on how to talk about Java access control mechanism. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.