11GOCP 1Z0-052 :2013-09-11 MGR_ROLE ROLE......A66

correct answer A



Experimental test

1. Create a user: SKD

gyj@OCM> create user SKD identified by SKD;

User created.


2. Authorization

gyj@OCM> grant connect,resource to SKD;

Grant succeeded.


3. Create the role MGR_ROLE according to the meaning of the question



gyj@OCM> create role MGR_ROLE;

Role created.




4. Query role



gyj@OCM> select * from dba_role_privs where grantee='MGR_ROLE';

no rows selected

gyj@OCM> select * from role_sys_privs where role='MGR_ROLE';

no rows selected

gyj@OCM> select * from role_tab_privs where role='MGR_ROLE';

no rows selected




5. Authorize the role MGR_ROLE according to the title



gyj@OCM> grant create role to MGR_ROLE;

Grant succeeded.

gyj@OCM> grant create user to MGR_ROLE;

Grant succeeded.
gyj@OCM> grant select any table to MGR_ROLE;

Grant succeeded.




6. Query ROLE again

gyj@OCM> select * from dba_role_privs where grantee='MGR_ROLE';

no rows selected

gyj@OCM> select * from role_sys_privs where role='MGR_ROLE';

ROLE PRIVILEGE ADM
---------------------------------------- -------------------- -------------------- ---
MGR_ROLE SELECT ANY TABLE NO
MGR_ROLE CREATE ROLE NO
MGR_ROLE CREATE USER NO

gyj@OCM> select * from role_tab_privs where role='MGR_ROLE';

no rows selected


7. Use OEM to check, which is consistent with the meaning of the question





8. Log in with SKD user to check your current permissions

gyj@OCM> conn SKD/SKD
Connected.
skd@OCM> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION
UNLIMITED TABLESPACE
CREATE TABLE
CREATE CLUSTER
CREATE SEQUENCE
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE

10 rows selected.




10. Use WITHADMIN OPTION to authorize roles for SKD users

WITH ADMIN OPTION means that the user who is granted the privilege has the right to grant a privilege (such as MGR_ROLE) to other users or roles, and cancellation is not cascaded.



gyj@OCM> GRANT MGR_ROLE TO SKD WITH ADMIN OPTION;

Grant succeeded.




11. Check the current permissions of the SKD user again, and there are three more items, namely the role MGR_ROLE, which means that the SKD user now has 13 system permissions.

skd@OCM> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION
UNLIMITED TABLESPACE
CREATE USER
CREATE TABLE
SELECT ANY TABLE
CREATE CLUSTER
CREATE SEQUENCE
CREATE ROLE
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE

13 rows selected.


12. Create a user a and grant only the CREATE SESSION system authority



gyj@OCM> create user a identified by a;

User created.

gyj@OCM> grant create session to a;

Grant succeeded.




13. Check that the current user a has only one permission to create a session

gyj@OCM> conn a/a
Connected.
a@OCM> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION


Answer A is correct, it can be granted the MGR_ROLE permission, but not other permissions under the SKD user, because the operation of the above step 8 GRANT MGR_ROLE TO SKD WITH ADMIN OPTION; adds WITH ADMIN OPTION.

The experiment is as follows:

a@OCM> conn SKD/SKD
Connected.
skd@OCM> grant MGR_ROLE to a;

Grant succeeded.

skd@OCM> grant CREATE TABLE to a;
grant CREATE TABLE to a
*
ERROR at line 1:
ORA-01031: insufficient privileges




Answer B is incorrect, not only can it reclaim the MGR_ROLE role granted by itself (with admin option added to the authorization), but also can actually reclaim the MGR_ROLE role that was not directly granted by him, I will give it to user a through SKD user first. , the a user gives the hr user, and then uses the SKD user to take back the hr user's MGR_ROLE role. When you can't figure out whether this question is right or wrong, it is generally not right to bring only a small skill.

The English of this question is a bit confusing, and it took me a long time to finally understand it. The technology is so hard. It is easy to understand if you understand it, but it is difficult to understand no matter how simple it is.



a@OCM> conn SKD/SKD
Connected.
skd@OCM> grant mgr_role to a with admin option;


Grant succeeded.


skd@OCM> conn a/a
Connected.
a@OCM> grant mgr_role to hr;


Grant succeeded.


a@OCM> conn SKD/SKD
Connected.
skd@OCM> revoke mgr_role from hr;

Revoke succeeded.

Answer C is incorrect, you can use WITHADMIN OPTION;


skd@OCM> grant mgr_role to a with admin option;

Grant succeeded.

Answer D is incorrect, permission can be revoked

skd@OCM> revoke mgr_role from a;
Revoke succeeded.

QQ: 252803295

Technical exchange QQ group:
DSI&Core Search Ⅰ group: 127149411 (2000 people technical group: less than full)
DSI&Core Search Ⅱ group: 177089463 (1000 people technical group: less than full)
DSI&Core Search Ⅲ group: 284596437 (500 people technical group: less than full)
DSI&Core Search IV group: 192136702 (500 people technical group: less than full)
DSI&Core Search Ⅴ group: 285030382 (500 people chat group: less than full)

(correct answer A
Experimental test
1. Create a user: SKD
gyj@OCM > create user SKD identified by SKD;
User created.
2. Authorization
gyj@OCM > grant connect,resource to SKD;
Grant succeeded.
3. Create the role MGR_ ROLE according to the meaning of the question
gyj@OCM > create role MGR_ ROLE;
Role created.
4. Query role
gyj@OCM > select * from dba_ role_ privs where grantee='MGR_ ROLE';
no rows selected
gyj@OCM > select * from role_ sys_ privs where role='MGR_ ROLE';
no rows selected
gyj@OCM > select * from role_ tab_ privs where role='MGR_ ROLE';
no rows selected
5. Authorize the role MGR_ ROLE according to the title
gyj@OCM > grant create role to MGR_ ROLE;
Grant succeeded.
gyj@OCM > grant create user to MGR_ ROLE;
Grant succeeded.
gyj@OCM > grant select any table to MGR_ ROLE;
Grant succeeded.
6. Query ROLE again
gyj@OCM > select * from dba_ role_ privs where grantee='MGR_ ROLE';
no rows selected
gyj@OCM > select * from role_ sys_ privs where role='MGR_ ROLE';
ROLE PRIVILEGE ADM
---------------------------------------- -------------------- -------------------- ---
MGR_ ROLE SELECT ANY TABLE NO
MGR_ ROLE CREATE ROLE NO
MGR_ ROLE CREATE USER NO
gyj@OCM > select * from role_ tab_ privs where role='MGR_ ROLE';
no rows selected
7. Use OEM to check, which is consistent with the meaning of the question
8. Log in with SKD user to check your current permissions
gyj@OCM > conn SKD/SKD
Connected.
skd@OCM > select * from session_ privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
UNLIMITED TABLESPACE
CREATE TABLE
CREATE CLUSTER
CREATE SEQUENCE
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE
10 rows selected.
10. Use WITHADMIN OPTION to authorize roles for SKD users
WITH ADMIN OPTION means that the user who is granted the privilege has the right to grant a privilege (such as MGR_ROLE) to other users or roles, and cancellation is not cascaded.
gyj@OCM > GRANT MGR_ ROLE TO SKD WITH ADMIN OPTION;
Grant succeeded.
11. Check the current permissions of the SKD user again, and there are three more items, namely the role MGR_ ROLE, which means that the SKD user now has 13 system permissions.
skd@OCM > select * from session_ privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
UNLIMITED TABLESPACE
CREATE USER
CREATE TABLE
SELECT ANY TABLE
CREATE CLUSTER
CREATE SEQUENCE
CREATE ROLE
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE
13 rows selected.
12. Create a user a and grant only the CREATE SESSION system authority
gyj@OCM > create user a identified by a;
User created.
gyj@OCM > grant create session to a;
Grant succeeded.
13. Check that the current user a has only one permission to create a session
gyj@OCM > conn a/a
Connected.
a@OCM > select * from session_ privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
Answer A is correct, it can be granted the MGR_ ROLE permission, but not other permissions under the SKD user, because the operation of the above step 8 GRANT MGR_ ROLE TO SKD WITH ADMIN OPTION;  adds WITH ADMIN OPTION.
The experiment is as follows:
a@OCM > conn SKD/SKD
Connected.
skd@OCM > grant MGR_ ROLE to a;
Grant succeeded.
skd@OCM > grant CREATE TABLE to a;
grant CREATE TABLE to a
*
ERROR at line 1:
ORA-01031: insufficient privileges
Answer B is incorrect, not only can it reclaim the MGR_ ROLE role granted by itself (with admin option added to the authorization), but also can actually reclaim the MGR_ ROLE role that was not directly granted by him, I will give it to user a through SKD user first. ,  the a user gives the hr user, and then uses the SKD user to take back the hr user's MGR_ ROLE role.  When you can't figure out whether this question is right or wrong, it is generally not right to bring only a small skill.
The English of this question is a bit confusing, and it took me a long time to finally understand it.  The technology is so hard.  It is easy to understand if you understand it, but it is difficult to understand no matter how simple it is.
a@OCM > conn SKD/SKD
Connected.
skd@OCM > grant mgr_ role to a with admin option;
Grant succeeded.
skd@OCM > conn a/a
Connected.
a@OCM > grant mgr_ role to hr;
Grant succeeded.
a@OCM > conn SKD/SKD
Connected.
skd@OCM > revoke mgr_ role from hr;
Revoke succeeded.
Answer C is incorrect, you can use WITHADMIN OPTION;
skd@OCM > grant mgr_ role to a with admin option;
Grant succeeded.
Answer D is incorrect, permission can be revoked
skd@OCM > revoke mgr_ role from a;
Revoke succeeded.
QQ: 252803295
Technical exchange QQ group:
DSI&Core Search Ⅰ group: 127149411 (2000 people technical group: less than full)
DSI&Core Search Ⅱ group: 177089463 (1000 people
)