In your multitenant container database (CDB) containing pluggable database (PDBs), the HR user
executes the following commands to create and grant privileges on a procedure:
CREATE OR REPLACE PROCEDURE create_test_v (v_emp_id NUMBER, v_ename
VARCHAR2, v_SALARY NUMBER, v_dept_id NUMBER)
BEGIN
INSERT INTO hr.test VALUES (V_emp_id, V_ename, V_salary, V_dept_id);
END;
/
GRANT EXECUTE ON CREATE_TEST TO john, jim, smith, king;
How can you prevent users having the EXECUTE privilege on the CREATE_TEST procedure from
inserting values into tables on which they do not have any privileges?
A.
Create the CREATE_TEST procedure with definer’s rights.
B.
Grant the EXECUTE privilege to users with GRANT OPTION on the CREATE_TEST
procedure.
C.
Create the CREATE_TEST procedure with invoker’s rights.
D.
Create the CREATE_TEST procedure as part of a package and grant users the EXECUTE
privilege the package.
Explanation:
If a program unit does not need to be executed with the escalated privileges of the
definer, you should specify that the program unit executes with the privileges of the caller, also
known as the invoker. Invoker’s rights can mitigate the risk of SQL injection.
Incorrect:
Not A: By default, stored procedures and SQL methods execute with the privileges of their owner,
not their current user. Such definer-rights subprograms are bound to the schema in which they
reside.
not B: Using the GRANT option, a user can grant an Object privilege to another user or to
PUBLIC.
The question is badly worded and misleading. The presence of a CDB & PDBs is irrelevant. This question is about PL/SQL code security from an invoker and definer point of view. By default, the AUTHID of a PL/SQL block is DEFINER, even if the AUTHID clause is omitted. That means when an invoker executes the PL/SQL, it runs as if it’s being run by the owner (DEFINER). That also means any object the PL/SQL references (e.g. a table) works because the owner (DEFINER) of the PL/SQL has access to the objects even if the user executing the PL/SQL (invoker) does not. Conversely, if AUTHID were CURRENT_USER, meaning the invoker, the execution of the PL/SQL would fail unless the invoker also had explicit access to the objects the PL/SQL code references.
Typos aside (e.g. the procedure is called CREATE_TEST_V but the GRANT statement references CREATE_TEST), the question should read:
How can you prevent users who have execute privilege on the CREATE_TEST_V procedure from inserting values into tables on which they do not have any privileges?
The given answer (C) means use AUTHID CURRENT_USER when creating the procedure CREATE_TEST_V. However, if you did that, then executed the procedure as a user other than the HR owner, (e.g. john, jim, smith or king) it wouldn’t work because those users have not been granted the INSERT privilege on the TEST table owned by HR.
So, within the context of the information given in the question, the given answer (C) is wrong. In a more generic sense, restricting access to only those objects for which a user has been granted explicit privileges, then using AUTHID CURRENT_USER (i.e. invoker’s right) is correct.
H*T*H.
nice explanation…..thanks
C