How to restrict one user making DDL changes in another schema

Question

can anyone please let me know the way to restrict a user making the DDL changes Through Procedure (This user have the execute privilege on procedure owner by another schema) on another schema.
Let say we have schema A and B. our requirement is, The User A should grant execute privilege on all the procedure that are created on A to user B, but if at all there is a situation a procedure is created with DDL changes(with execute immediate option) and gave the execute privilege to the user B, Then user B can make DDL changes through this procedure. i wanted to restrict user B making DDL changes any way to user A .
Appreciate your help.
Thanks,
Karthik

Answer 1

Your requirement doesn't sound terribly sensible.  If you want B to be able to execute the procedure, grant B access to the procedure.  If you don't want B to be able to execute the procedure, don't grant B access.  If you are concerned that someone is going to change the code in the procedure after it is created to transform it from something that you want B to have access to into something that you don't want B to have access to, you should be reviewing changes before they are promoted.
If you're really determined to do things "uniquely", I suppose you could create a DDL trigger that looks to see who the user is and throws an exception if it is B.  But that seems like a poor second choice to dealing with the problem sensibly from the outset.
If you aren't reviewing the changes and building code that tries to check whether something bad got slipped in, you're going to be fighting a losing battle.  If you write a DDL trigger that checks the user, for example, and I'm a developer that's intent on creating holes, I could simply add code to a procedure that submits a dbms_job that executes DDL.  That job would run as A so your DDL trigger would let it pass.  Of course, you could then turn around and disable DBMS_JOB in which case I could use DBMS_SCHEDULER instead.  You could disable that as well but then you're disabling the scheduler jobs that Oracle runs by default for things like gathering statistics.  And then the rogue developer simply moves on to the next hole to exploit.
Justin