A detailed introduction to the Oracle L3 permission system and a detailed introduction to the oracle L3 Permission System

A detailed introduction to the Oracle L3 permission system and a detailed introduction to the oracle L3 Permission System

The Oracle user object permission system is an important part of Oracle database security management. Oracle user permissions are a flexible and configurable management system. In this article, we will talk about Oracle's three-tier permission system.

1. role, system, and object

In the Oracle user permission system, all permissions are implemented on the user owner. The user needs the corresponding permissions (such as createsession) to perform any operations, including database connection. In other words, the user owner cannot do anything without corresponding permissions.

From the content level, Oracle's permission system is divided into three layers: role, system, and object. The following is a simple description:

1. object privilege is the minimum granularity object of the permission system. The feature is that the permission point is on the object. Objects here, including permissions for eleven objects, including data tables, views, sequences, packages, and stored procedures, in the Oracle system. Each object has its own permissions. For example, you have select, update, and other operation permissions on a data table;

2. system privilege is another layer that describes Oracle user operations. Defines what users can do in the system, such as Createtable. Note that some system permissions and object permissions may overlap. Use it with caution.

Role privilege is a combination of object permissions, system permissions, and even role permissions. Object permissions and system permissions are fine-grained permission units. A type of user usually needs the same object permission set and system permission set. If you set the roles separately, there may be omissions. It is easier to set the role based on the responsibilities, and then attach the role to the user;

2. object permission: object privilege

The object permission is the basic permission of Oracle, which defines the permissions that a user can use on a specific object. Note: The object permission mentioned here is the permission for an existing object. Currently, Oracle supports nine-sided permissions for eleven objects, not all nine-sided permissions for each type of object. The following table details:

As shown in the preceding table, the permissions that can be granted vary with objects. In addition, there is an implicit all permission, indicating all the permissions that an object can grant.

View, you can use views such as user_tab_privilege and table_privilege to check the access authorization of objects.

3. System permission System Privilege

System permissions specify what actions a user can perform in the system, including targeting objects and systems. System permissions are defined in Oracle, and there are about 160 system permissions in Oracle10g.

For example, if you create a new user without any permissions, the user does not even have the logon permission. In this case, you must grant the system permission (or connect role) to the user to create a session.

System permissions are very fragmented and meticulous. We need a series of system permission configurations to allow users to create a simple connection table or even insert records. Is there a way to simplify the operation? The answer is to use predefined or custom role permissions.

4. role permission role privilege

The role-based permission system is a commonly used access control policy in the system. The role-based system not only achieves fine-grained permission division, but also ensures the role and position setting. A role is a simple permission container that can include many types of system permissions, object permissions, and even role permissions.

We can check the permission settings through two views: user_role_privs and dba_role_privs.

In the actual development process, there are not many scenarios for custom roles, because there are many restrictions in the development and use of custom role permissions. There are many scenarios where we use predefined permissions, such as connect and resource, and even dba and imp_full_database, which are the role permissions that we often use.