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

This article introduces how to test the non-cascade recall phenomenon of Privilege Oracle system permissions, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

Oracle permissions are divided into system permissions and object permissions. Here we will show you a special scenario in the process of system permission granting and recycling: the phenomenon of non-cascading withdrawal of system permissions.

Three users were involved in the experiment: SYS users, secooler1 users and secooler2 users.

1. Clean up and initialize users

1) Clean up test users secooler1 and secooler2

Sys@secdb > drop user secooler1

User dropped.

Sys@secdb > drop user secooler2

User dropped.

2) create test users secooler1 and secooler2

Sys@secdb > create user secooler1 identified by secooler1

User created.

Sys@secdb > create user secooler2 identified by secooler2

User created.

two。 Authorize secooler1 and secooler2 users

1) SYS users use the with admin option option to grant secooler1 users the system permission to create a session

Sys@secdb > grant create session to secooler1 with admin option

Grant succeeded.

2) the user who connects to secooler1 grants the right to create a session to the secooler2 user

Because secooler1 has admin permission, you can grant the right to create a session to another user again, where the right to create a session is granted to the secooler2 user.

Sys@secdb > conn secooler1/secooler1

Connected.

Secooler1@secdb > grant create session to secooler2

Grant succeeded.

3. View the grant of system permissions

1) Connect to SYS user

Secooler1@secdb > conn / as sysdba

Connected.

2) View the system permissions of the secooler1 user

Sys@secdb > select * from dba_sys_privs where grantee='SECOOLER1'

GRANTEE PRIVILEGE ADM

-

SECOOLER1 CREATE SESSION YES

The secooler1 user has permission to create a session, as well as the admin option.

3) View the system permissions of the secooler2 user

Sys@secdb > select * from dba_sys_privs where grantee='SECOOLER2'

GRANTEE PRIVILEGE ADM

-

SECOOLER2 CREATE SESSION NO

The secooler2 user has permission to create a session.

4. Use the SYS user to reclaim the create session rights of the secooler1 user

Sys@secdb > revoke create session from secooler1

Revoke succeeded.

5. Confirm the result of system permission recovery

Sys@secdb > select * from dba_sys_privs where grantee='SECOOLER1'

No rows selected

Sys@secdb > select * from dba_sys_privs where grantee='SECOOLER2'

GRANTEE PRIVILEGE ADM

-

SECOOLER2 CREATE SESSION NO

It can be seen that the permission of the secooler1 user to create the session has been recovered successfully, but note that the permission of the secooler2 user to create the session has not been cascaded. This is the characteristic of the system privilege recovery process.

6. Test the result of user permission recovery

Sys@secdb > conn secooler2/secooler2

Connected.

Secooler2@secdb > conn secooler1/secooler1

ERROR:

ORA-01045: user SECOOLER1 does not have CREATE SESSION permission; login is denied

Warning: You are no longer connected to ORACLE.

It can be seen that the secooler2 user can still connect successfully at this time, because the right of the secooler2 user to create the session has not been cascaded.

7. Summary

Oracle system permissions do not have the function of cascading recall. Pay attention to the comprehensiveness of permission revocation when using authorization with the admin option.

Good luck.

Secooler

11.10.25

On how to carry out the Privilege Oracle system permissions non-cascade recall phenomenon test is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.