Oracle Database User Management II --- Authorization and authorization (users and roles)
The book is connected last time, https://blog.csdn.net/alwaysbefine/article/details/112133204 , Oracle system is very complicated from the perspective of installation, use after installation and subsequent maintenance. Similarly, Oracle has a user system. How to recognize and manage these users is a relatively basic and important issue.
1. The built-in user composition of the Oracle database system :
Just after installing the Oracle software, Oracle provides some built-in users and roles in the system. These user roles can be called basic users (roles). Through the SQL statement select * from dba_users order by username; all users of the system can be queried , The number of built-in users may be different depending on the components selected during installation (there is no special verification, it should be so), but most users are locked and their passwords expired. Among them, sys, system, scott The user is an out-of-the-box user, and the sys login usually needs to specify the identity as sysdba, which is the system administrator identity, the system user has its own dba role, and the scoot user is a normal user and is generally locked (unlike other The user is locked and the password has expired, the user does not have a password, just a locked state). In other words, after the installation is complete, the available users provided by the system are three, sys, system, and scoot.
sys is powerful, equivalent to the root user in the Linux system, the five permanent members of the Security Council, and the god in the Oracle system.
System has 6 less permissions than sys, but because it has the role of dba, it is also powerful, equivalent to the second in command, God's deputy, and the only second boss in the Oracle system.
Scoot is the name of the first programmer recruited by Alison, Oracle. It is an ordinary user set up just to commemorate this programmer named Silent. It has very few permissions and roles.
So, lock the remaining users when they are locked, and expire when the password expires. We don’t use them either. We just need to customize the user and assign custom user permissions and roles. Therefore, if sys, system, and scoot users have set passwords, please keep them in mind. (Usually, the passwords of these users are set during installation. You cannot install Oracle without setting the passwords of these users: laugh~~~).
Summary: After installing the Oracle system, take a good look at the system's built-in users, there are not many, 11g only has about 30, and most of them are unavailable users whose locks have expired. Keep in mind the SQL statement:
select * from dba_users order by username;
2. All permissions of the Oracle database system :
Query all permissions: log in to the sys user and execute the SQL statement: select * from session_privs order by PRIVILEGE; --Other users can only find 202 permissions, and all other users can query 202 permissions. The output is as follows: permissions can be divided into system permissions and object permissions. (For example, select table is an object authority. Objects usually refer to objects such as tables and views. The permissions such as alter user, create user, and create role are divided into system permissions)
ADMINISTER ANY SQL TUNING SET
ADMINISTER DATABASE TRIGGER
ADMINISTER RESOURCE MANAGER
ADMINISTER SQL MANAGEMENT OBJECT
ADMINISTER SQL TUNING SET
ADVISOR
ALTER ANY ASSEMBLY
ALTER ANY CLUSTER
ALTER ANY CUBE
ALTER ANY CUBE DIMENSION
ALTER ANY DIMENSION
ALTER ANY EDITION
ALTER ANY EVALUATION CONTEXT
ALTER ANY INDEX
ALTER ANY INDEXTYPE
ALTER ANY LIBRARY
ALTER ANY MATERIALIZED VIEW
ALTER ANY MINING MODEL
ALTER ANY OPERATOR
ALTER ANY OUTLINE
ALTER ANY PROCEDURE
ALTER ANY ROLE
ALTER ANY RULE
ALTER ANY RULE SET
ALTER ANY SEQUENCE
ALTER ANY SQL PROFILE
ALTER ANY TABLE
ALTER ANY TRIGGER
ALTER ANY TYPE
ALTER DATABASE
ALTER DATABASE LINK
ALTER PROFILE
ALTER PUBLIC DATABASE LINK
ALTER RESOURCE COST
ALTER ROLLBACK SEGMENT
ALTER SESSION
ALTER SYSTEM
ALTER TABLESPACE
ALTER USER
ANALYZE ANY
ANALYZE ANY DICTIONARY
AUDIT ANY
AUDIT SYSTEM
BACKUP ANY TABLE
BECOME USER
CHANGE NOTIFICATION
COMMENT ANY MINING MODEL
COMMENT ANY TABLE
CREATE ANY ASSEMBLY
CREATE ANY CLUSTER
CREATE ANY CONTEXT
CREATE ANY CUBE
CREATE ANY CUBE BUILD PROCESS
CREATE ANY CUBE DIMENSION
CREATE ANY DIMENSION
CREATE ANY DIRECTORY
CREATE ANY EDITION
CREATE ANY EVALUATION CONTEXT
CREATE ANY INDEX
CREATE ANY INDEXTYPE
CREATE ANY JOB
CREATE ANY LIBRARY
CREATE ANY MATERIALIZED VIEW
CREATE ANY MEASURE FOLDER
CREATE ANY MINING MODEL
CREATE ANY OPERATOR
CREATE ANY OUTLINE
CREATE ANY PROCEDURE
CREATE ANY RULE
CREATE ANY RULE SET
CREATE ANY SEQUENCE
CREATE ANY SQL PROFILE
CREATE ANY SYNONYM
CREATE ANY TABLE
CREATE ANY TRIGGER
CREATE ANY TYPE
CREATE ANY VIEW
CREATE ASSEMBLY
CREATE CLUSTER
CREATE CUBE
CREATE CUBE BUILD PROCESS
CREATE CUBE DIMENSION
CREATE DATABASE LINK
CREATE DIMENSION
CREATE EVALUATION CONTEXT
CREATE EXTERNAL JOB
CREATE INDEXTYPE
CREATE JOB
CREATE LIBRARY
CREATE MATERIALIZED VIEW
CREATE MEASURE FOLDER
CREATE MINING MODEL
CREATE OPERATOR
CREATE PROCEDURE
CREATE PROFILE
CREATE PUBLIC DATABASE LINK
CREATE PUBLIC SYNONYM
CREATE ROLE
CREATE ROLLBACK SEGMENT
CREATE RULE
CREATE RULE SET
CREATE SEQUENCE
CREATE SESSION
CREATE SYNONYM
CREATE TABLE
CREATE TABLESPACE
CREATE TRIGGER
CREATE TYPE
CREATE USER
CREATE VIEW
DEBUG ANY PROCEDURE
DEBUG CONNECT SESSION
DELETE ANY CUBE DIMENSION
DELETE ANY MEASURE FOLDER
DELETE ANY TABLE
DEQUEUE ANY QUEUE
DROP ANY ASSEMBLY
DROP ANY CLUSTER
DROP ANY CONTEXT
DROP ANY CUBE
DROP ANY CUBE BUILD PROCESS
DROP ANY CUBE DIMENSION
DROP ANY DIMENSION
DROP ANY DIRECTORY
DROP ANY EDITION
DROP ANY EVALUATION CONTEXT
DROP ANY INDEX
DROP ANY INDEXTYPE
DROP ANY LIBRARY
DROP ANY MATERIALIZED VIEW
DROP ANY MEASURE FOLDER
DROP ANY MINING MODEL
DROP ANY OPERATOR
DROP ANY OUTLINE
DROP ANY PROCEDURE
DROP ANY ROLE
DROP ANY RULE
DROP ANY RULE SET
DROP ANY SEQUENCE
DROP ANY SQL PROFILE
DROP ANY SYNONYM
DROP ANY TABLE
DROP ANY TRIGGER
DROP ANY TYPE
DROP ANY VIEW
DROP PROFILE
DROP PUBLIC DATABASE LINK
DROP PUBLIC SYNONYM
DROP ROLLBACK SEGMENT
DROP TABLESPACE
DROP USER
ENQUEUE ANY QUEUE
EXECUTE ANY ASSEMBLY
EXECUTE ANY CLASS
EXECUTE ANY EVALUATION CONTEXT
EXECUTE ANY INDEXTYPE
EXECUTE ANY LIBRARY
EXECUTE ANY OPERATOR
EXECUTE ANY PROCEDURE
EXECUTE ANY PROGRAM
EXECUTE ANY RULE
EXECUTE ANY RULE SET
EXECUTE ANY TYPE
EXECUTE ASSEMBLY
EXEMPT ACCESS POLICY
EXEMPT IDENTITY POLICY
EXPORT FULL DATABASE
FLASHBACK ANY TABLE
FLASHBACK ARCHIVE ADMINISTER
FORCE ANY TRANSACTION
FORCE TRANSACTION
GLOBAL QUERY REWRITE
GRANT ANY OBJECT PRIVILEGE
GRANT ANY PRIVILEGE
GRANT ANY ROLE
IMPORT FULL DATABASE
INSERT ANY CUBE DIMENSION
INSERT ANY MEASURE FOLDER
INSERT ANY TABLE
LOCK ANY TABLE
MANAGE ANY FILE GROUP
MANAGE ANY QUEUE
MANAGE FILE GROUP
MANAGE SCHEDULER
MANAGE TABLESPACE
MERGE ANY VIEW
ON COMMIT REFRESH
QUERY REWRITE
READ ANY FILE GROUP
RESTRICTED SESSION
RESUMABLE
SELECT ANY CUBE
SELECT ANY CUBE DIMENSION
SELECT ANY DICTIONARY
SELECT ANY MINING MODEL
SELECT ANY SEQUENCE
SELECT ANY TABLE
SELECT ANY TRANSACTION
SYSDBA
SYSOPER
UNDER ANY TABLE
UNDER ANY TYPE
UNDER ANY VIEW
UNLIMITED TABLESPACE
UPDATE ANY CUBE
UPDATE ANY CUBE BUILD PROCESS
UPDATE ANY CUBE DIMENSION
UPDATE ANY TABLEThese permissions are commonly used to create tables, delete tables, modify tables, create and delete user roles, and establish connections. For example, create table, create any table, create user, create session, create role, and so on.
Query all the permissions of a user: select * from session_privs order by PRIVILEGE;-This user needs to log in, and the query is the user’s system permissions
The above 202 permissions are all system permissions. Commonly used permissions are all permissions related to tables and views, that is, permissions that include the words table and view. For example, create table, create any table (any means there is no user restriction, for example, to create a table, with this any permission, you can create a table for any user, including yourself)
3. The built-in roles of the Oracle database system :
What the hell is the character? In fact, a role is a logical collection of permissions. Speaking of people, a role is given a name after a combination of permissions. Since it is a set, the permissions are the smallest granularity, which means that a role may have only one permission. There may also be n permissions. Some specified permissions are gathered together and a name is given, and this name is the role.
So, what are the logical collections of permissions---roles? The SQL query statement is: select * from dba_roles order by role; There are about 50 built-in roles in the 11g version, and one role is called dba.
This dba is the boss of the role, and the basic database permissions are owned by this role. To view the permissions owned by a role, here is the role of dba as an example, the SQL statement is as follows:
select * from role_sys_privs where role='DBA' order by PRIVILEGE;
The output is roughly as above, you can see that the role permissions of dba cover all aspects, system permissions, and object permissions are basically there. In fact, the biggest reason why the system described above is so extraordinary is because of the role of dba.
The SQL statement that proves that the system user has the dba role is: SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE ='SYSTEM';-query the role of the system user.
Similarly, to query what roles the user scott has, the SQL statement is: SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE ='SCOTT'; - query the roles owned by the scott user.
It should be reminded here that all the content in the quotation marks following grantee must be all uppercase to find the content, otherwise no error will be reported and no content will be returned.
In other words, the role dba is the boss of all roles, and basically all permissions are included in this role.
Another commonly used role is resource. You can see what permissions the resource role has: select * from role_sys_privs where role='RESOURCE' order by PRIVILEGE; Of course, the role of resource has relatively few dba permissions and is suitable for some basic tasks. Tasks, such as building a table for personal use, etc.
There is also a hidden role. You can't see the intangible role public. Many people say that it is a collection of all users. Here, the benevolent sees the benevolent and the wise. Because this thing is hidden, a lot of bloody winds are caused by it. How bloody winds are something later, I will talk about this public in detail later.
4. Combination and separation of users and permissions---authorization and deprivation :
Permissions are to users, just like salt and bread, like water and food. Users must have permissions to play a role. Only permissions can limit what users can and cannot do. In the Oracle system, users with permissions that are not granted by default It cannot be used. Only when a certain permission is granted can the user do what is allowed by this permission, such as create user. Only this user has this permission or has inherited this permission to create a new user. With so much nonsense, let’s talk about authorization and right to go.
(1) The SQL statement for creating a new user zsk is as follows: create user zsk;-use the system or sys user to create a new user, because there are only two high-privileged users at the beginning, so there is no choice.
(2), or execute the SQL statement under the sys user: SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE ='ZSK'; - There is no output, indicating that this user is indeed a clean user without any permissions
(3), grant statement, grant xxx, xxx, xxxx to user name; for example, SQL statement: grant create session, create table, create any table to zsk; --- Grant user zsk login and table creation permissions. These three permissions are system permissions, not object permissions. Therefore, the permission to query it is: select * from dba_sys_privs where grantee='ZSK';--The output result is:
It should be noted that the value of the third option admim_option is no, which means that the user zsk does not have the authority to grant his own authority to other users. This is what we often call cascading authorization.
At the same time, there are two suffixes when granting rights, one is with admin option, for example, the above statement plus this suffix is: grant create session,create table,create any table to zsk with admin option;-
The SQL statement to query the system privileges of zsk is: select * from dba_sys_privs where grantee='ZSK'; -The output result is:
At this time, the user of zsk has the right to grant its existing permissions with the value of the admin_option column value to others. In other words, if there is a permission of yes, it can be passed to other users, for example, to add a new user. zsk1, then log in to the user zsk, and assign the above three permissions to zsk1. As long as the three permissions are yes, then other users must be authorized. People who have been engaged in operation and maintenance for a long time will immediately understand. It's sudo. Yes, cascade is sudo.
Another suffix is with grant option. This suffix is for sudo object permissions. If you are not convinced, huh, I will use this suffix to give system permissions to sudo. I'm sorry, I will report an error. For example, still the above empowerment:
The system clearly tells you, that is, the last line of the above figure, it asks you to specify the admin option. Now, friends don't have to worry about being confused between system permissions and object permissions.
Object permissions are select, drop, alter, update, truncate, insert permissions for table and view operations, such as querying a user's own table, deleting a table under a user, etc. These are object permissions.
Then, we query the permissions of the access$ table under the sys user for the zsk user without adding the sudo permission suffix. The SQL statement is: grant select on sys.access$ to zsk;
At this point, to query the object permissions of the zsk user, the SQL statement is: select * from dba_tab_privs where grantee='ZSK'; --The output is as follows:
At this time, the value of the sixth column is no. If the sudo suffix is added, the sixth column will become yes. The SQL statement is: grant select on sys.access$ to zsk with grant option;
The query for the object permissions of the zsk user is: select * from dba_tab_privs where grantee='ZSK';--Please note the difference between the two greens
The granting of system permissions is generally the to user, and the granting of object permissions is generally the on user .
(4), the right to operate
revoke permission from user; For example, the above zsk user now has four permissions, now remove its new table permission, query the sys user table access$ permission, you can do this:
revoke create table,create any table from zsk;
revoke select on sys.access$ from zsk;
There are three points to pay attention to to remove the right. 1. Use and separate multiple permissions of the same type. 2. System permissions and object permissions cannot be mixed, that is, write system permissions and object permissions, and then revoke, which will report an error. Similarly, you cannot mix when granting rights. 3. After the deprivation is successful, the deprivation cannot be repeated, otherwise an error will be reported.
5. Role empowerment and de-authorization operations :
In order to better explain this problem, use the newly created user zsk and system administrator user sys to operate.
(1) User name and role name cannot be the same
First landing sys users to see how many characters: the SELECT * from DBA_ROLES by the Order Role; - can not see zsk this role,
Check which users are there, select * from dba_users order by username;--you can see that there is a user named zsk.
create role zsk;--At this time, an error will be reported, and the user name and role cannot be repeated. Therefore, the role name is changed to zsk_role. Create a new one again: create role zsk_role; The role is successfully created.
(2) Check what permissions does this newly created role zsk_role have now?
select * from role_sys_privs where role='ZSK_ROLE' order by PRIVILEGE;--I did not find any permissions for the role
(3) Give the role of zsk_role the system permissions of the new user create user
grant create user to zsk_role;--You can see that there is basically no change between role empowerment and user empowerment
(4) Assign the role to the user zsk
grant zsk_role to zsk;-Assign roles to users like a permission.
(5) Log in to the zsk user, create another ordinary user, and check if there is a new user authority.
You can see that the zsk user has the authority to create a new user.
(6) Log in to the sys user at this time, check the permissions of zsk and you will not see the create user permission, but you can see the role of zsk_role when you query the role owned by zsk.
select * from dba_tab_privs where grantee='ZSK';
SELECT GRANTEE,GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE ='ZSK';
( 7 ) Log in to the sys user and give the zsk_role the permission to query the alter_qt table under sys
grant select on sys.alert_qt to zsk_role;--At this time, switch to the zsk user, and you can query the alert_qt table under sys.
(8), a user multi-role problem-activation and forbidden role permissions.
As mentioned earlier, a role is a collection of permissions. The above experiment has also verified that any permissions can be stuffed into a role, but a user can have multiple roles. Assuming that zsk users have many roles, at this time, we have to select a role It is the default role. This selected action is called activation.
The SQL statement is: set role zsk_role;--Operate under the zsk user, then the permissions of other roles will not take effect, and only use the permissions of the zsk_role role.
What if any role is not like using it, and you just want to use the permissions directly granted by other users? Execute the SQL statement: set role none;
Switch to the zsk user and execute set role none; - At this time, creating a new user will not succeed. In other words, set role none; means that the user does not use any role.
in conclusion:
select * from dba_roles order by role;--all roles
select * from dba_users order by username;--all users
select * from dba_tab_privs where grantee='ZSK';--Query the object permissions of the zsk user, zsk can be replaced with any user you want to query. Advanced permissions can be inquired
select * from dba_sys_privs where grantee='ZSK';--Query the system permissions of the zsk user, zsk can be replaced with any user you want to query. Advanced permissions can be inquired
select * from role_sys_privs where role='ZSK_ROLE' order by PRIVILEGE;--Query the system privileges of this role zsk_role
select * from role_sys_privs where role='DBA' order by PRIVILEGE;--Query the system privileges of the role dba. 202 records.
select * from role_tab_privs where role='ZSK_ROLE' order by PRIVILEGE;--Query the role's object permissions
select * from role_tab_privs where role='DBA' order by PRIVILEGE;--Query the object privileges of this role dba. 284 records.
select * from session_privs order by PRIVILEGE;--You need to log in to this user, and you need to query the system permissions of this user. You need to log in to execute the query, and you can only query the system permissions of the current user.
Pay attention to cascading empowerment, which is similar to the sudo empowerment of the Linux system. Don't expect the two kinds of permissions to be mixed.