Security problem? (ORA-00942 error when creating procedure)

Question

First, in SQL*Plus connect as system user:
SQL>connect system/oracle
Then, create table proctest for user scott and insert records:
SQL>create table scott.proctest ( name varchar2(10)) ;
SQL>insert into scott.proctest values ( 'bigboy' ) ;
SQL>select * from scott.proctest ;
NAME
bigboy
Then, create procedure testproc for user system using table scott.proctest:
SQL>CREATE OR REPLACE PROCEDURE testproc AS
2 v_name VARCHAR2(10) ;
3 BEGIN
4 SELECT Name INTO v_name FROM scott.proctest WHERE rownum < 2 ;
5 DBMS_OUTPUT.PUT_LINE( 'Name: ' || v_name ) ;
6 END ;
7 /
Then, errs report:
SQL>show err;
LINE/COL ERROR
4/2 PL/SQL: SQL
4/2 PL/SQL: SQL Statement ignored
4/37 PL/SQL: ORA-00942: Table or view does not exist
Then, explicitly grant select privilege on proctest to system:
SQL>grant select on scott.proctest to system ;
And at this time compile the above precedure again, there's no errors.
I have got some instruction that if a procedure wants to use some table,
the owner of this procedure has to have corresponding privileges to use this table and
these privileges have to be granted directly to the user. It doesn't work if
the privileges are granted i.e. through roles.
And in the example above the user has select on scott.proctest privilege but
this privilege is granted through DBA role. So it doesn't work if
I do not explicitly grant select privilege to system.
My question is:
Why does Oracle define this rule? Is it a kind of security consideration?

Answer 1

Since stored procedures rely on privileges that are granted directly to the user, Oracle only needs to re-validate stored procedures when direct grants to the schema owner change. In general, the rate at which the privileges assigned to roles are changed is much higher than the rate at which privileges assigned to a particular user are changed, so this cuts down on on the cost of revalidating procedures.
More importantly, Oracle roles can be assigned to users, but a user can also have non-default roles and password-protected roles. If Oracle allowed privileges through roles to affect the privileges of a stored procedure, handling these sorts of cases would be quite difficult and would result in far more confusion than in today's implementation.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC