說說Oracle三層許可權體系（下）

Oracle使用者物件許可權體系是Oracle資料庫安全管理中重要的組成部分。Oracle使用者許可權是一套靈活可配置的管理體系。本篇我們從幾個使用Oracle許可權體系中的問題細節入手，做一些有趣的嘗試。

 

 

1、  角色role迴圈賦予實驗

 

角色許可權、系統許可權和物件許可權，三者構成了Oracle許可權體系的主幹。其中，系統許可權（system privilege）和物件許可權（object privilege）是原子性許可權，也就是不能相互之間包括容納。

 

而角色許可權（role privilege）具有兩個特性，其一是可自定義特性，其二是可包容巢狀特性。所謂可包容巢狀特性就是說角色可以包括其他的系統許可權和物件許可權，甚至包括其他角色許可權。那麼，會不會出現角色之前的迴圈授予問題呢？我們透過下面的實驗來確定。

 

//自定義兩個空許可權角色；

SQL> create role r_t;

Role created

 

SQL> create role r_m;

Role created

 

//相互嘗試賦予許可權；

SQL> grant r_t to r_m;

Grant succeeded

 

SQL> grant r_m to r_t;

grant r_m to r_t

 

ORA-01934: 檢測到迴圈的角色授權

 

 

實驗結論顯而易見。Oracle在進行grant角色相關授權的時候，會自動進行迴圈檢測，如果發現迴圈，就禁止掉操作。

 

這讓我們想起Oracle對死鎖也有類似的檢測機制，詳見筆者的文章《Oracle中的死鎖》（http://space.itpub.net/17203031/viewspace-682115）。

 

 

2、  角色許可權在儲存過程中的剔除效應

 

角色的確是一種很方便的許可權集合組織方式，在很多系統中也是廣泛應用。但是在Oracle中，使用角色許可權role privilege是要格外小心的，特別是進行資料庫開發過程中。因為Oracle儲存過程等結構對角色許可權有剔除效應。

 

首先我們準備實驗環境。

 

//建立實驗角色r_cat_role

SQL> create role r_cat_role ;

Role created

 

//授予系統許可權select any dictionary給實驗角色

SQL> grant select any dictionary to r_cat_role;

Grant succeeded

 

//建立使用者

SQL> create user mytest identified by mytest;

User created

 

SQL> grant create session to mytest;

Grant succeeded

 

SQL> grant r_cat_role to mytest;

Grant succeeded

 

SQL> grant create procedure to mytest;

Grant succeeded

 

 

實驗中，mytest使用者只具有基本的連線許可權和以後實驗用到的create procedure許可權。此外只有使用的角色許可權r_cat_role。

 

角色許可權r_cat_role中具有了select any dictionary的系統許可權。該許可權下，使用者可以訪問到Oracle的大部分後設資料檢視。而這個許可權對於一般使用者而言顯然是不具備的。

 

 

SQL> conn mytest/mytest@ora11g;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as mytest

 

SQL> select count(*) from dba_objects;

 

  COUNT(*)

----------

     72282

 

 

dba_objects檢視是後設資料字典的一個組成部分。mytest使用者在接受角色許可權r_cat_role之後，具有了在SQL中直接使用的許可權。下面我們構造儲存過程如下：

 

 

SQL> create or replace procedure P_TEST_NC

  2  is

  3  n_res number;

  4  begin

  5    select count(*)

  6    into n_res

  7    from dba_objects;

  8 

  9    dbms_output.put_line(to_char(n_res));

 10  end P_TEST_NC;

 11  /

 

Warning: Procedure created with compilation errors

 

SQL> select * from user_errors;

 

NAME       TYPE           SEQUENCE       LINE   POSITION TEXT                                     ATTRIBUTE

---------- ------------ ---------- ---------- ---------- ---------------------------------------- ---------

P_TEST_NC  PROCEDURE    1   7 8 PL/SQL: ORA-00942: 表或檢視不存在        ERROR    

P_TEST_NC  PROCEDURE  2  5   3 PL/SQL: SQL Statement ignored            ERROR      

 

 

編譯報錯，看起來不可思議。明明mytest使用者具有dba_objects檢視的訪問許可權，而且在SQL語句直接可以使用。為什麼在SP中使用就不可以了呢？

 

我們說，就是因為訪問dba_objects的許可權是透過角色授予的。儲存過程等Oracle程式碼結構具有一個特性，就是可以將使用者的三層許可權（role、system和object）中的role許可權剝離掉。

 

mytest是透過角色r_cat_role來獲取到的select any dictionary系統許可權的。在進入sp定義的時候，角色就被剝離掉。所以沒有對dba_objects訪問的許可權。

 

解決問題的辦法，就是放棄使用角色許可權而直接進行系統許可權授予。

 

 

SQL> conn sys/oracle@ora11g as sysdba;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as SYS

 

SQL> revoke r_cat_role from mytest;

Revoke succeeded

 

SQL> grant select any dictionary to mytest;

Grant succeeded

 

 

重新實驗，建立儲存過程。

 

 

SQL> conn mytest/mytest@ora11g;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as mytest

 

SQL> select count(*) from dba_objects;

 

  COUNT(*)

----------

     72283

 

SQL> create or replace procedure P_TEST_NC

  2  is

  3  n_res number;

  4  begin

  5    select count(*)

  6    into n_res

  7    from dba_objects;

  8 

  9    dbms_output.put_line(to_char(n_res));

 10  end P_TEST_NC;

 11  /

 

Procedure created

 

 

實驗成功。

 

經過上面的兩個實驗，我們發現Oracle的role許可權不像想象的那麼高效，而且存在一定的複雜性。那麼實際上，我們真正有很多相同職責的Oracle使用者嗎？很多時候，我們的系統是不會讓Oracle與使用者直接聯絡的，都是透過前端應用以一個統一的名稱進行訪問。角色特別是自定義角色使用的場景很少。

 

所以，筆者的想法是，除了進行特定的資料庫操作，使用預定義Oracle角色許可權外，不要嘗試自己去定義角色。此外，對許可權還是使用直接的物件、系統許可權賦予較好。

 

3、系統許可權和物件許可權衝突實驗

 

系統許可權中包括一部分與物件有關的內容。如select any table、execute any procedure等。這些和物件許可權之間存在一些重疊的部分。那麼，會不會出現對特定物件的衝突呢？

 

首先我們檢查一般的情況。

 

 

SQL> create user mytest identified by mytest;

User created

 

SQL> grant connect, resource to mytest;

Grant succeeded

 

SQL> grant select any table to mytest;

Grant succeeded

 

 

在scott使用者下。

 

 

SQL> conn scott/tiger@orcl;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as scott

 

SQL> create table m as select * from all_tables;

Table created

 

 

具有select any table的使用者mytest是可以直接select使用者scott的資料表m的。

 

 

SQL> conn mytest/mytest@orcl;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as mytest

 

SQL> select count(*) from scott.m;

 

  COUNT(*)

----------

       104

 

 

嘗試可否從scott使用者上禁止mytest對m的訪問。

 

 

SQL> conn scott/tiger@orcl;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as scott

 

SQL> revoke select on t from mytest;

 

revoke select on t from mytest

 

ORA-01927: 無法 REVOKE 您未授權的許可權

 

 

可見看出，對Oracle的revoke而言，只能revoke授予過的許可權。未授予過的許可權，或者嘗試對系統許可權、物件許可權語義的拆分，都是不能做到的。

 

那麼，擁有select any table，就可以任意select了嗎？未必。我們一起來繼續看。

 

//在sys使用者下，建立資料表t；

SQL> show user

User is "SYS"

 

SQL> create table t as select * from dba_objects;

Table created

 

SQL> conn mytest/mytest@orcl;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as mytest

 

SQL> select count(*) from sys.t;

select count(*) from sys.t

 

ORA-00942: 表或檢視不存在

 

 

可以看出，雖然mytest擁有select any table許可權，但是對sys使用者下的資料表，是不能訪問的。這是Oracle內部對於sys使用者核心物件的一種保護措施。

 

如果要讓mytest能訪問到sys.t物件，需要進行顯示的物件許可權object privilege賦值。

 

 

SQL> show user

User is "SYS"

 

SQL> grant select on t to mytest;

Grant succeeded

 

SQL> conn mytest/mytest@orcl;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as mytest

 

SQL> select count(*) from sys.t;

 

  COUNT(*)

----------

     51369

 

 

顯然，sys下的物件往往需要進行顯示的物件許可權賦值。

 

 

4、  結論

 

上面三個實驗，簡單挖掘了一下許可權體系的一些細節問題。很多時候，我們會遇到很多複雜的需求場景，把握許可權系統各層次的本質特性，進行合理評估和分析試驗，就能實現很多看似不可能做到的任務。