overview

The ORACLE database system pre-defines five roles of CONNECT, RESOURCE, DBA, EXP_FULL_DATABASE, and IMP_FULL_DATABASE.
CONNECT has privileges to create tables, views, sequences, etc.; (alter session create cluster)
RESOURCE has privileges to create procedures, triggers, tables, sequences, etc.,
DBA has all system privileges;
EXP_FULL_DATABASE, IMP_FULL_DATABASE has privileges to unload and load databases.

Permission classification

System authority: The system stipulates the user's authority to use the database. (system permissions are for users).
Entity permission: A user with a certain permission has access to other users' tables or views. (for tables or views).

System rights management

DBA: Has all privileges and is the highest authority of the system. Only DBA can create database structures.
RESOURCE: Users with Resource permissions can only create entities, not database structures.
CONNECT: Users with Connect privileges can only log in to Oracle, but cannot create entities or database structures.
For ordinary users: grant connect, resource permissions.
For DBA management users: grant connect, resource, dba permissions.

[System authority can only be granted by DBA user: sys, system (only these two users at first)]
Authorization command: SQL> grant connect, resource, dba to username 1 [, username 2]…;
[ Ordinary users can have the same user rights as system through authorization, but they can never achieve the same rights as sys users, and the system user's rights can also be revoked. ]
Example: SQL> connect system/manager
SQL> Create user user50 identified by user50;
SQL> grant connect, resource to user50;
Query what permissions the user has:
SQL> select * from dba_role_privs;
SQL> select * from dba_sys_privs;
SQL> select * from role_sys_privs;
Delete user: SQL> drop user user name cascade; //Add cascade to delete the user and all the things it created

Entity rights management

1. Classification of entity permissions: select, update, insert, alter, index, delete, all //all including all permissions
execute //permission to execute stored procedures
user01:
SQL> grant select, update, insert on product to user02;
SQL> grant all on product to user02;
user02:
SQL> select * from user01.product;
// At this time, user02 checks user_tables, which does not include the table user01.product, but if you check all_tables, you can find it, because he can access it.
2. Grant the operation permission of the table to all users:
SQL> grant all on product to public; // public means all users, and the all permission here does not include drop.
[Entity permission data dictionary]:
SQL> select owner, table_name from all_tables; // Tables that users can query
SQL> select table_name from user_tables; // Tables created by users
SQL> select grantor, table_schema, table_name, privilege from all_tab_privs; / / Tables that are authorized to be accessed (authorized)
SQL> select grantee, owner, table_name, privilege from user_tab_privs; // Table of granted privileges (granted privileges)
to view which system rights the user has
Sql> select grantee, privilege from dba_sys_privs where grantee='SCOTT';
view the user's own Which object rights
Sql> select grantee, privilege, owner, table_name from dba_tab_privs where grantee='SCOTT';
3. DBA users can operate any base table of all users (no authorization, including deletion):
DBA users:
SQL> Create table stud02 .product(
id number(10),
name varchar2(20));
SQL> drop table stud02.emp;
SQL> create table stud02.employee
as
select * from scott.emp;
4. Entity permission transfer (with grant option):
user01:
SQL> grant select, update on product to user02 with grant option; // user02 has the permission and can pass it on.
5. Recycling of entity authority:
user01:
SQL>Revoke select, update on product from user02; //All passed permissions will be lost.
Explanation
1) If the object permission of a user is canceled, the same permission of these users will also be canceled for the users granted permission by this user using WITH GRANT OPTION
, that is to say, cascading when canceling the authorization.

role management

I explained permissions and users in the previous section. Slowly in use, you will find a problem: if there is a group of people, their required permissions are the same, and it will be very difficult to manage their permissions.

convenient. Because you want to manage the permissions of each user in this group.
There is a good solution: roles. A role is a collection of permissions. Assign a role to a user, and the user will have all the permissions in the role. Then the above problems are
easy to deal with, as long as the role is assigned to this group of users for the first time, and then only need to manage the role.
The above is a typical use of roles. In fact, just understand that a role is a collection of permissions.

1. Create a role
sql>create role role1;
2. Authorize the
role sql>grant create any table, create procedure to role1;
Sql>grant create session, create table to role1;
Sql>revoke create session, create table from role1;

3. Grant roles to users
sql>grant role1 to user1;
Sql>grant role1 to user1 with admin option;

revoke role1 from user1;

View all roles in the system
Sql>select * from dba_roles;

Check which roles the user has been granted
Sql>select grantee, granted_role from dba_role_privs where grantee='SCOTT';
check which system permissions are included in the role
Sql>select role, privilege from role_sys_privs where role='ROLE1';

Check which object permissions are included in the role
Sql>select role, privilege, from role_tab_privs where role='ROLE1';
grant the role to the role
Sql>grant role1 to role2;

4. View the permissions contained in the role
sql>select * from role_sys_privs;
5. Create a role with a password (the password must be provided when the role with a password takes effect)
sql>create role role1 identified by password1;
6. Modify the role: Do you need a password? sql>alter role role1 not identified;
sql>alter role role1 identified by password1;
7. Set the role to be effective for the current user
(Note: What is the concept of the effective role? Suppose user a has b1, b2, b3 Three roles, then if b1 is not in effect, the permissions contained in b1 are not owned by a. Only when the role is in effect, the permissions in the role will be applied to the user. The maximum number of valid roles is set by the parameter MAX_ENABLED_ROLES; After the user logs in, oracle assigns all the permissions directly assigned to the user and the permissions in the default role of the user to the user.)
sql>set role role1;//Make role1 take effect
sql>set role role,role2;//Make role1, role2 takes effect
sql>set role role1 identified by password1;//use role1 with a password to take effect
sql>set role all;//use all roles of the user to take effect
sql>set role none;//set all roles to fail
sql>set role all except role1;//All other roles of this user except role1 take effect.
sql>select * from SESSION_ROLES;//Check the effective roles of the current user.
8. Modify the specified user and set its default role
sql>alter user user1 default role role1;
sql>alter user user1 default role all except role1;
see the oracle reference document for details
9. Delete the role
sql>drop role role1;
after the role is deleted, the original The user who owns the role no longer owns the role, and the corresponding permissions are gone.
Note:
1) You cannot use WITH GRANT OPTION to grant object privileges to a role
2) You can use WITH ADMIN OPTION to grant system privileges to a role, and it is not a cascade when canceling
Check which roles are still included in
the role Sql>select role，granted_role from role_role_privs where role= 'DBA';
Remarks: After the user is granted the roles of DBA and RESOURCE, the system will automatically grant the user unlimited tablespace

Permissions, roles and user management