(转+整理) oracle authid definer 与 authid current_user

转：http://blog.csdn.net/indexman/article/details/17067531

　　http://blog.csdn.net/liqfyiyi/article/details/7441706

oracle DB下面有2种执行的权限：定义者权限（Definer）和调用者权限(Invoker)。

• AUTHID DEFINER （定义者权限）：指编译存储对象的所有者。也是默认权限模式。

　　定义者权限的现象是，如果在APPS下创建的procedure，那其他user，只要能执行procedure，都是以apps的名义来执行的。因为APPS是procedure的定义者。
APPS能做什么，那这个procedure就能做什么。

• AUTHID CURRENT_USER（调用者权限）：指拥有当前会话权限的模式，这可能和当前登录用户相同或不同(alter session set current_schema 可以改变调用者Schema)

　　调用者权限的现象是,如果在APPS下创建的procedure，如果其他user有权限执行这个procedure，这个procedure所做的内容都是以当前user的名义来做的。如果某个table，只有APPS才有权限修改，那这个procedure在apps下面才执行成功。其他user下是不成功的。

官方的解释：

By default, stored procedures and SQL methods execute with the privileges of their owner, not their current user. Suchdefiner's rights subprograms are bound to the schema in which they reside, allowing you to refer to objects in the same schema without qualifying their names. For example, if schemas HR and OEboth have a table called departments, a procedure owned by HR can refer to departments rather than HR.departments. If user OE calls HR's procedure, the procedure still accesses the departments table owned by HR.

A more maintainable way is to use the AUTHID clause, which makes stored procedures and SQL methods execute with the privileges and schema context of the calling user. You can create one instance of the procedure, and many users can call it to access their own data.

默认情况，程序以其拥有者身份（定义者）执行。定义者权限的程序与其所在模式绑定，调用对象不需要加上模式完整名称。例如，假如模式HR和OE都有deparments表，HR拥有的程序可直接调用departments而不用HR.departments.而如果OE调用HR的程序，程序仍然调用的是HR的departments.

如果希望不同模式(schema)调用相同的程序却可以操作各自拥有的对象，就可以在定义程序的时候加上AUTHID CURRENT_USER。

在一些技术论坛里面，常常看到有朋友问这种问题： 为什么我的用户具有DBA权限，却无法在存储过程里面创建一张普通表呢？
下面就结合具体案例来谈谈这个问题：
SQL> conn eric/eric;
Connected.SQL> select * from dba_role_privs where grantee='ERIC';
 
GRANTEE                        GRANTED_ROLE                   ADM DEF
------------------------------ ------------------------------ --- ---
ERIC                           DBA                            NO  YES
ERIC                           CONNECT                        NO  YES
ERIC                           RESOURCE                       NO  YES
ERIC                           RECOVERY_CATALOG_OWNER         NO  YES
可以看到，用户eric拥有 DBA 权限！ 
用此用户创建一个存储过程：
create or replace procedure p_CreateTable
as
begin
 execute immediate 'create table test_tb(id number)';
end p_CreateTable;
/
Procedure created.
运行时会发现，系统提示权限不足（insufficient privileges）！
SQL> exec p_CreateTable;
BEGIN p_CreateTable; END;
*
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "ERIC.P_CREATETABLE", line 3
ORA-06512: at line 1
 由上可以看到，即使拥有DBA role，也不能创建表。即 role在存储过程中不可见!
查阅资料发现:
Oracle8i以前的版本，所有已编译存储对象,包括packages, procedures, functions, triggers, views等，只能以定义者(Definer)身份解析运行；
而Oracle8i及其后的新版本，Oracle引入调用者(invoker)权限，使得对象可以以调用者身份和权限执行。
遇到这种情况，通常解决方法是进行显式的系统权限: grant create table to eric;但是，此方法太笨，因为有可能执行一个存储过程，
需要很多不同权限（oracle对权限划分粒度越来越细）。
最好的方法是，利用 oracle 提供的方法，在创建存储过程时，加入 Authid Current_User 条件进行权限分配。
create or replace procedure p_CreateTable Authid Current_User
as
begin
 execute immediate 'create table test_tb(id number)';
end p_CreateTable;
/
Procedure created.
SQL> exec p_CreateTable;
PL/SQL procedure successfully completed.
SQL> desc test_tb
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 ID                                                 NUMBER
 成功啦！！！
由此可以引申出一个问题：
如果用户B要执行A用户的某存储过程，传统的解决方案是：
A用户将此存储过程的执行权限赋予B用户：
grant execute on p_test to B;
在B用户下创建一个同义词：
create synonym p_test for a.p_test;
然后B用户就可以直接执行p_test了.
但是，如果使用 Authid Current_User 选项，在创建时给调用者授权，就简单多了！