Procedure to move table - running procedure as woner not caller

Question

I seem to remember there is a way of getting a procedure to run as the user owning it rather than the one calling this. This is my main question. Below is some background. The other thing I am trying work out is what is the best way of doing a grant from a procedure, I guess execute immediate is the way to go.
Background:
OK, this may seem a strange requirement but as there is no safe way of allowing a user to create/drop tables in a different (team shared) schema we are planing on getting the user to create the table in there own schema and then call a procedure to move it to team schema.
I think this can be done with 2 procedures (possibly in a single package).
a) move_table_to_team - owned by team with user1 having execute permissions.
b) move_table_to_team_remote - owned by team with user1 having execute permissions BUT run as team schema (i.e. the scema owning proc) not user calling it (so it can create tables).
So the steps are:
1) user1 creates table table1
2) user1 calls move_table_to_team('table1');
3) move_table_to_team grants select on table1 to team schema
4) move_table_to_team calls move_table_to_team_remote(username,team1).
5) move_table_to_team_remote does a 'create table team.table1 as select * from user1.table1 where 1=2'
6) retrun to move_table_to_team
7) drop table1.
Regards,
Ben

Answer 1

Hi, Ben,
orangetwig wrote:
I seem to remember there is a way of getting a procedure to run as the user owning it rather than the one calling this. This is my main question. That's right:
CREATE OR REPLACE PACKAGE  pkg_name
AUTHID  DEFINER
AS ...Actually, DEFINER is the default invoker-rights. You only have to specify AUTHID when you want the package to run with the caller's privilegers:
CREATE OR REPLACE PACKAGE  pkg_name
AUTHID  CURRENT_USER
AS ...
Below is some background. The other thing I am trying work out is what is the best way of doing a grant from a procedure, I guess execute immediate is the way to go.Yes, use EXECUTE IMMEDIATE in PL/SQL for everything except queries and DML.
Background:
OK, this may seem a strange requirement but as there is no safe way of allowing a user to create/drop tables in a different (team shared) schema we are planing on getting the user to create the table in there own schema and then call a procedure to move it to team schema.Yes, that's a problem. To create (or drop) a table in sombody else's schema, you need the privileges to create (or drop) tables in anybody else's schema, and you don't want to grant that to lots of people.
Can't you allow the individual developers to log in as the team user when they need to create (or drop) tables there? If the team owns other objects, and you want to prevent users from tanpering with them, you could create a team_transfer schema, that contains only the tables copied from the individual users, and have them log in to that.
I think this can be done with 2 procedures (possibly in a single package).
a) move_table_to_team - owned by team with user1 having execute permissions.
b) move_table_to_team_remote - owned by team with user1 having execute permissions BUT run as team schema (i.e. the scema owning proc) not user calling it (so it can create tables).
So the steps are:
1) user1 creates table table1
2) user1 calls move_table_to_team('table1');
3) move_table_to_team grants select on table1 to team schema
4) move_table_to_team calls move_table_to_team_remote(username,team1).
5) move_table_to_team_remote does a 'create table team.table1 as select * from user1.table1 where 1=2'
6) retrun to move_table_to_team
7) drop table1.
Regards,
BenStep 5 has to be done with the team privileges, but steps 1, 3 and 7 have to be doen with the individual's privileges. I think you'll need two packages, one with AUTHID DEFINER to create or drop objects in the team schema, and the other with AUTHID CURRENT_USER to create or drop objects in the individual schemas. A package can call procedures in another package, so the user can do the whole job with just one call.