Problem in Select rights

Question

I have defined a role as:
create role my_role;
Then I granted the select on USER1.Table1 as:
Grant select on User1.Table1 to my_role:
Then I granted the role to User2 as:
grant my_role to User2;
Now I am able to execute the following query while I am connected with User2:
select * from User1.Table1;
All is working fine.
Now I have writen a procedure in User2 As
Create or replace procedure User2.someProceduere
cur_test out sys_refcursor
Begin
Opne cur_test
for 'select * from User1.Table1';
End;
While I runt this procedure it produces the error message
"Table or view does not exists"
Intrestingly when I give direct rights on User1.Table1 to User2 the procudure statrs working, without any error
(From direct rights I mean to say when I do not give rights through the roile "my_role"
instead I write:
grant select on User1.Table1 to User2;)
I want to know the reason? I am confused, because when I give rights through the role the procedure does not work
and when I give rights directly to the user the procudue starts working.
Edited by: Sayyed_Kamran on Aug 11, 2010 1:40 AM

Answer 1

Right. This is written in detail in the Oracle documentation. Some portion from that:
>
How Roles Work in PL/SQL Blocks
The use of roles in a PL/SQL block depends on whether it is an anonymous block or a named block (stored procedure, function, or trigger), and whether it executes with definer's rights or invoker's rights.
Roles Used in Named Blocks with Definer's Rights
All roles are disabled in any named PL/SQL block (stored procedure, function, or trigger) that executes with definer's rights. Roles are not used for privilege checking and you cannot set roles within a definer's rights procedure.
The SESSION_ROLES view shows all roles that are currently enabled. If a named PL/SQL block that executes with definer's rights queries SESSION_ROLES, then the query does not return any rows.
http://download.oracle.com/docs/cd/B28359_01/network.111/b28531/authorization.htm#DBSEG004
>
>
A unit whose AUTHID value is CURRENT_USER is called an invoker's rights unit, or IR unit. A unit whose AUTHID value is DEFINER is called a definer's rights unit, or DR unit. An anonymous block always behaves like an IR unit. A trigger or view always behaves like a DR unit.
The AUTHID property of a unit determines whether the unit is IR or DR, and it affects both name resolution and privilege checking at run time:
* The context for name resolution is CURRENT_SCHEMA.
* The privileges checked are those of the CURRENT_USER and the enabled roles.
When a session starts, CURRENT_SCHEMA has the value of the schema owned by SESSION_USER, and CURRENT_USER has the same value as SESSION_USER. (To get the current value of CURRENT_SCHEMA, CURRENT_USER, or SESSION_USER, use the SYS_CONTEXT function, documented in Oracle Database SQL Language Reference.)
CURRENT_SCHEMA can be changed during the session with the SQL statement ALTER SESSION SET CURRENT_SCHEMA. CURRENT_USER cannot be changed programmatically, but it might change when a PL/SQL unit or a view is pushed onto, or popped from, the call stack.
Note:
Oracle recommends against issuing ALTER SESSION SET CURRENT_SCHEMA from within a stored PL/SQL unit.
During a server call, when a DR unit is pushed onto the call stack, the database stores the currently enabled roles and the current values of CURRENT_USER and CURRENT_SCHEMA. It then changes both CURRENT_USER and CURRENT_SCHEMA to the owner of the DR unit, and enables only the role PUBLIC. (The stored and new roles and values are not necessarily different.) When the DR unit is popped from the call stack, the database restores the stored roles and values. In contrast, when an IR unit is pushed onto, or popped from, the call stack, the values of CURRENT_USER and CURRENT_SCHEMA, and the currently enabled roles do not change.
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28370/subprograms.htm#LNPLS00809