Definer rights VS. invoker rights (same old story...)

Question

/Disclaimer:/
Look, I know that this one has been discussed like hundreds of times already...
Anyway, as I was browsing the forum yesterday, I have noticed this thread:
Re: Different data dictionaries inside stored procedures?
and it actually reminded me of a question I once had but never got the anwser.
So, here goes...
Imagine a pretty common situation of a DBA creating a new user account 'JOHN' and granting John some privileges:
create user john identified by xxxxx default tablespace .... ;
grant connect to john;
grant create procedure to john;Afterwards John opens a session, creates the following PL/SQL procedure and executes it:
create or replace procedure table_creator (tab_name varchar2)
is
begin
  execute immediate 'create table '||tab_name||' (n number)';
end;
exec table_creator('test')And we all know what happens:
BEGIN table_creator('test'); END;
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "JOHN.TABLE_CREATOR", line 5
ORA-06512: at line 1Now, the 2 well-known solutions to this problem are:
1) grant create table to john; (and thus do not rely on roles);
2) create or replace procedure table_creator (tab_name varchar2) authid current_user is...
My question is: which one of the two above is the best one?
I mean, the first solution seems pretty straightforward, but then the question that emerges is why do we have roles anyway if we can't truly rely on them (?)
As for the second one, there're issues like performance downgrade due to runtime name/privilege resolution, etc.
Or is there some other way to go?
Message was edited by:
iferous

Answer 1

// ACEs where r u ?!Oh don't Re: Needs another simple fix ! (Its been over 24hrs, nobody tried! Strange) Alex, I thought you were one of the good guys.
Anyway, I expect a lot of the Aces are in the air right now, heading for 'Frisco.
To your question:
which one of the two above is the best one?It depends. Is John a developer or a user? If John is a developer then the DBA should grant him privileges explicitly. If John is a user then it is appropriate to use a role for his privileges and thus use the AUTHID CURRENT_USER approach.
Note, I think this example is flawed because I would not expect a user to have a procedure which dynamically creates a table. Certainly I wouldn't expect John as a user to be creating procedures or to know about invoker rights. But the same model applies if the privilege is say SELECT access on another user's tables.
the question that emerges is why do we have roles anyway if we can't truly rely on them (?)In my view ROLES are intended for managing users rather than developers. Generally I think this means granting table privileges to roles but not system privileges (although CREATE SESSION is an obvious exception). We should not use Roles for managing the privileges of developers, or for application owner accounts come to that. If the account has a schema it probably should have individually granted system privileges; as with most generalisations there is a grey area.
Cheers, APC
Message was edited by: inserting the crucial NOT that makes the sentence make sense
APC