Invoker Rights Part 1

Truth suffers from too much analysis. Frank Herbert In the Oracle database you have a choice of two models for executing the PL/SQL code. The default model (and the only one available until Oracle 8i (8.1.7)) is the Definer Rights model. When using this model the program executes under the authority of the owner (or creator) of the program. The

Truth suffers from too much analysis.
Frank Herbert

In the Oracle database you have a choice of two models for executing the PL/SQL code. The
default model (and the only one available until Oracle 8i (8.1.7)) is the Definer Rights model.
When using this model the program executes under the authority of the owner (or creator) of the
program. The other model is the Invoker Rights model. When using this model the program
executes under the authority of the invoker of the program. This means data and objects that
are available to the user are also available to the program. When running the code using the
Definer Rights model, the data and objects available to the definer of the code are available to
the code. This might mean a user may have access to data he is not supposed to have
access to. There are some differences between both models and your programs may run using a
combination of the two.

Definer Rights

A PL/SQL program must be compiled and stored in the database before it can be executed. Any
reference in the code is resolved at compile time. This means the program must have directly
granted access to these objects. They are not resolved using roles granted to the definer or
owner of the program. Although the references are checked against the rights the owner has,
you can still grant execute rights to different schemas or users. Keep in mind though that when
another user executes the code, it runs under the authority of the definer of the code. This
means this user has access to all the objects needed by the code, while the user might not have
access to these objects either through directly granted privileges or through a role. This may be
a good thing when you want to make sure the user accesses tabledata only through a defined
interface (Table API) but if you want the user to see certain parts of the data, when different
parts should be hidden from him/her it means either building more code to hide parts of the data
or resort to Virtual Private Databases.

Invoker Rights

The other model available to you is the Invoker Rights model. In this model the code is executed
under the authority of the schema (or user) that started the code. This means that all objects
needed by the code need to be available to the invoker of the code. References are checked to
the references available to the rights the invoker has, instead of the rights the definer of the
code has. This means that every user that executes the code can have different objects
available than the ones available to the definer. If the code, for instance, references a table then
this table can be a completely different object than the one used by the compiling schema. This
way you can make sure the user only has access to his own data. If multiple users use the
same code to reference, for instance, a clients table, the different users will see different results.
This way you can easily implement a model where users have access to only their own data,
without the need for Virtual Private Databases or more code. Be aware though that when you
call a Definer Rights defined program from within an Invoker Rights program; from that time
on you will be using the rights for that Definer. If you are to call another Invoker rights program it
will be executed under the authority of that Definer, rather then the Invokers authority. If this
program calls an Invoker Rights program it will be executed under the authority of the Definer of
the program that was just called rather than the authority of the original invoker.

Ref:
Oracle PL/SQL Programming 5th Edition – Steven Feuerstein
tahiti.oracle.com – all Oracle Documentation online