PL/SQL Reference VII - Invoker's vs Definer's rights

===========================================
Definer's Right vs Invoker's Right
===========================================
Consider following situation:
User A does not have permissions to update table_X
User B has permissions to update table_X
User B creates a PL/SQL procedure proc_a to update table_X

User B grants execute on proc_a to user A.

Will user A be able to update table_ X via proc_a?

===========================================

Definer's Right
===========================================

This is default.

With Definer's Right - the question is "does user have permission to execute the PL/SQL code"?

The PL/SQL code is executing with the permissions of the creating user.

===========================================

Invoker's Right
===========================================

New from Oracle 8i.

With Invoker's Right - the question is "does user have permission to execute the commands within PL/SQL code"?

The PL/SQL code is executing with the permissions of the invoking user.

===========================================

Definer's Right is the preferred option.
===========================================

It is much more manageable.

1.Permissions

Otherwise all users would need DML permissions to database Objects, in order to execute PL/SQL code.

And it is a bad practice to grant users direct permissions to DML oprations. They should rather "pass" through the PL/SQL code.

2.Name Resolution.

With definer's right, references are resolved in definers schema.

With invoker's  right, this is complicated...

Packages, Procedures, Functions - are resolved in definer's schema.

Other objects are resolved in invoker's schema.