Definer and Invoker Rights In the program-based security model, we discussed a way the internal tables and other objects can be hidden from the view of the user who calls the procedure. User CLAIM_SCHEMA owns the table CLAIMS and the procedure pay_claim().
The user JUDY, a senior claim analyst, decides on the claim and when the time comes to pay, executes the procedure.
Nor does she have any other privileges : update, insert, or delete. However, she executes the procedure that updates the claims table.
Why does this procedure go through without any error? The procedure pay_claim() is owned by claim schema, which also owns the table claims.
Therefore, when Judy executes the procedure, she is actually using the privileges the procedure owner has been granted, not the ones she has been granted. p_claim_id IN number, p_paid_amount IN number ) authid current_user /* Important */ is begin update claims set paid_amount = p_paid_amount, status = 'P' where claim_id = p_claim_id; end; / Note that this is identical to the procedure pay_claim(), with the exception of the use of the clause authid current_user in the code. Let's see what happens when JUDY calls this procedure. Shouldn't Judy be successful in updating the claims table just like the earlier case? Since the procedure is defined as Invoker Rights model, the privileges enjoyed by Judy (the invoker) are used, not those of the owner of the procedure.
However, if the procedure were so generic that it is callable by any user to update his or her own tables, or tables owned by others they have privileges on, then authorization is almost nonexistent.
In other words, the program merely becomes a code execution piece, not an encapsulation device to be the sole operator of the objects.
The users have individual grants to the objects underneath, and use the program merely as code to execute steps. The user JUDY tries to select from the table CLAIMS, as follows, and gets an error.This is known as the Invoker Rights Model because the privileges of the invoker, not the definer of the programs, prevail. This is expected, since Judy does not have select privileges on the table.This is the simplest authorization scheme in programs, and is known as the definers rights model.Prior to Oracle 8i, this was the only model of authorization.So, what is the problem with this model' The problem occurs in situations where the program is too generic and is not tied to a specific user and its schema objects.In the pay_claim() procedure, we have determined that the procedure updates only objects owned by the user CLAIM_SCHEMA, who owns both the procedure and the object.