資料庫安全是一個內容豐富的體系結構，其中訪問控制和操作控制是安全體系的重要內容。Oracle資料庫作為目前最成熟的商用資料庫產品，其安全訪問體系是行業界普遍接受的標準。

Oracle資料庫許可權體系是一個典型的“許可性許可權”，也就是許可權單元的含義都是附加許可性的。Oracle從來就是規定某某使用者（角色）可以做什麼（System Privilege）或者對什麼物件做什麼（Object Privilege）。Oracle許可權體系包括三層組織單元：

ü 系統許可權（System Privilege）：規定了使用者（角色）可以做什麼；

ü 物件許可權（Object Privilege）：規定了使用者（角色）可以對某個特定物件做什麼；

ü 角色許可權（Role Privilege）：是三種許可權的集合體，在不出現迴圈結構的情況下，可以進行組合巢狀；

三層許可權操作體系構成了Oracle訪問控制的基石。下面對一些細節進行試驗，做出簡單的分析。

1、Role許可權的“非即時”設定

我們選擇在Oracle 10g上進行試驗。

SQL> select * from v$version;

BANNER

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

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

PL/SQL Release 10.2.0.1.0 - Production

CORE 10.2.0.1.0 Production

角色role的設定並不是即時的。只有在使用者重新登入或者手工的設定上角色（set role xxx）的時候，才能讓一個使用者新加入的角色進行生效。我們首先進行一個全新使用者的建立。

SQL> create user tim identified by tim;

User created

--授予一個基本的連線許可權

SQL> grant connect to tim;

Grant succeeded

使用新使用者許可權進行登入。

SQL> conn tim/tim@orcl

已連線。

--沒有建立資料表相關許可權；

SQL> create table t(id number);

create table t(id number)

*

第 1 行出現錯誤:

ORA-01031: 許可權不足

--檢視當前會話使用者具有的角色許可權；

SQL> select * from session_roles;

ROLE

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

CONNECT

--檢視當前使用者具有的系統許可權（包括角色許可權附加的內容。）

SQL> select * from session_privs;

PRIVILEGE

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

CREATE SESSION

SQL> select * from role_sys_privs where role='CONNECT';

ROLE PRIVILEGE ADMIN_OPTION

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

CONNECT CREATE SESSION NO

SQL> select * from dba_role_privs where grantee='TIM';

GRANTEE GRANTED_ROLE ADMIN_OPTION DEFAULT_ROLE

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

TIM CONNECT NO YES

角色許可權connect只包括一個系統許可權create session。

下面，我們嘗試去授予TIM resource操作許可權。注意，此時的TIM使用者保持會話連線。

SQL> grant resource to tim;

Grant succeeded

此時，保持連線的TIM使用者許可權體系如何呢？

SQL> select * from session_roles;

ROLE

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

CONNECT

SQL> select * from session_privs;

PRIVILEGE

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

CREATE SESSION

UNLIMITED TABLESPACE

SQL> create table t(id number);

create table t(id number)

*

第 1 行出現錯誤:

ORA-01031: 許可權不足

角色許可權是沒有出現在列表中，但是經常和resource伴隨的一個UNLIMITED TABLESPACE卻出現在列表中。同時，我們依然不能建立資料表。說明：在授予role許可權之後，使用者會話不能主動的獲取到許可權資訊，需要重新登入和set role強制方法。

SQL> set role resource;

角色集

SQL> select * from session_privs;

PRIVILEGE

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

UNLIMITED TABLESPACE

CREATE TABLE

CREATE CLUSTER

CREATE SEQUENCE

CREATE PROCEDURE

CREATE TRIGGER

CREATE TYPE

CREATE OPERATOR

CREATE INDEXTYPE

已選擇9行。

SQL> select * from session_roles;

ROLE

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

RESOURCE

SQL> create table t(id number);

表已建立。

我們可以看到幾個現象，透過set role命令，我們的確可以實現將最新設定的角色“啟用”給使用者。但是，這樣做也會將原有的角色替換掉（CONNECT角色消失）。

當TIM重新登入之後，一切恢復正常。

SQL> conn tim/tim@orcl

已連線。

SQL> select * from session_roles;

ROLE

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

CONNECT

RESOURCE

SQL> select * from session_privs;

PRIVILEGE

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

CREATE SESSION

UNLIMITED TABLESPACE

CREATE TABLE

CREATE CLUSTER

CREATE SEQUENCE

CREATE PROCEDURE

CREATE TRIGGER

CREATE TYPE

CREATE OPERATOR

CREATE INDEXTYPE

已選擇10行。

剛剛，我們發現了一個奇怪的unlimited tablespace許可權，與resource相關。下面，我們就一起來討論這個許可權的內容。

2、從角色許可權“分裂”談起

注意觀察的朋友可能都知道，當我們將使用者授予resource許可權之後，unlimited tablespace許可權是附加在使用者的許可權列表中的。看似是resource中包括了unlimited tablespace，才使得使用者具有這個許可權。但是，下面的試驗證明其中的不同。

我們對TIM使用者許可權進行操作。

SQL> revoke unlimited tablespace from tim;

Revoke succeeded

SQL> revoke create table from tim;

revoke create table from tim

ORA-01952: 系統許可權未授予 'TIM'

SQL> revoke create type from tim;

revoke create type from tim

ORA-01952: 系統許可權未授予 'TIM'

看出差異所在了嗎？從角色resource中帶出的系統許可權中，只有unlimited tablespace是可以被收回許可權的。

此時，Tim登入的許可權情況如下：

SQL> select * from session_privs;

PRIVILEGE

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

CREATE SESSION

CREATE TABLE

CREATE CLUSTER

CREATE SEQUENCE

CREATE PROCEDURE

CREATE TRIGGER

CREATE TYPE

CREATE OPERATOR

CREATE INDEXTYPE

已選擇9行。

SQL> select * from session_roles;

ROLE

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

CONNECT

RESOURCE

兩個細節，Unlimited Tablespace的確被剔除了，同時Resource角色許可權Oracle同樣承認。

我們檢查許可權檢視，可以證明這點。

SQL> select * from dba_role_privs where grantee='TIM';

GRANTEE GRANTED_ROLE ADMIN_OPTION DEFAULT_ROLE

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

TIM RESOURCE NO YES

TIM CONNECT NO YES

SQL> select * from dba_sys_privs where grantee='RESOURCE';

GRANTEE PRIVILEGE ADMIN_OPTION

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

RESOURCE CREATE TRIGGER NO

RESOURCE CREATE SEQUENCE NO

RESOURCE CREATE TYPE NO

RESOURCE CREATE PROCEDURE NO

RESOURCE CREATE CLUSTER NO

RESOURCE CREATE OPERATOR NO

RESOURCE CREATE INDEXTYPE NO

RESOURCE CREATE TABLE NO

8 rows selected

這個現象是什麼原因呢？我們重新建立一個新使用者進行試驗。

SQL> create user mt identified by mt;

User created

SQL> grant resource, connect to mt;

Grant succeeded

SQL> conn mt/mt@orcl

已連線。

SQL> select * from session_privs;

PRIVILEGE

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

CREATE SESSION

UNLIMITED TABLESPACE

CREATE TABLE

CREATE CLUSTER

CREATE SEQUENCE

CREATE PROCEDURE

CREATE TRIGGER

CREATE TYPE

CREATE OPERATOR

CREATE INDEXTYPE

已選擇10行。

SQL> select * from session_roles;

ROLE

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

CONNECT

RESOURCE

--此時，剔除許可權；

SQL> revoke resource from mt;

Revoke succeeded

此時，使用者MT重新登入後。

SQL> conn mt/mt@orcl;

已連線。

SQL> select * from session_roles;

ROLE

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

CONNECT

SQL> select * from session_privs;

PRIVILEGE

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

CREATE SESSION

Unlimited Tablespace許可權也跟著連帶剔除掉了。那麼，這個許可權是怎麼回事呢？

SQL> select * from dba_sys_privs where grantee='MT' or grantee='RESOURCE';

GRANTEE PRIVILEGE ADMIN_OPTION

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

RESOURCE CREATE SEQUENCE NO

RESOURCE CREATE TRIGGER NO

RESOURCE CREATE CLUSTER NO

RESOURCE CREATE PROCEDURE NO

RESOURCE CREATE TYPE NO

MT UNLIMITED TABLESPACE NO

RESOURCE CREATE OPERATOR NO

RESOURCE CREATE TABLE NO

RESOURCE CREATE INDEXTYPE NO

9 rows selected

從上面的檢視裡面，我們發現幾個問題：

首先，Resource角色集合中，根本就沒有包括Unlimited Tablespace系統許可權。其次，Unlimited Tablespace是直接賦予給MT使用者的。

說明：我們在將resource角色許可權賦予給使用者的時候，Oracle“偷偷”將這個系統許可權Unlimited Tablespace賦予給了使用者MT。如果我們收回這個角色許可權，Unlimited Tablespace也會“連帶”的被取回。兩個許可權是存在分離的可能的。

問題最後我們想一下：為什麼？

筆者猜想：Oracle在這裡面對一個兩難的局面。角色Resource的原始目的是希望進行一般的資料物件操作和建立的許可權。但是，在建立物件中，空間資源Tablespace是不可分開的資源。沒有配額的Create Table許可權是沒有任何意義的。所以，一種直觀的做法就是將Unlimited Tablespace授予給Resource角色。

但是，另一方面這樣也有問題。在生產環境下，空間使用，特別是每個使用者的空間使用都是有嚴格的管理的。Unlimited Tablespace在空間使用上的許可權太大，限制通用化有沒有什麼很好的方法。在正式生產環境下，使用者空間使用一定是透過配額而不是這個系統許可權來設定的。

這就遇到兩難。如果將這個Unlimited Tablespace放在Resource中，生產環境都不會使用到Resource這個角色了。

這裡，Oracle做了一點手腳。Resource和Unlimited Tablespace是可以同時設定和回收的。但是，透過revoke命令，我們是可以單獨將Unlimited tablespace進行剔除的。

3、結論

Oracle角色許可權有很多的細節和使用特性，需要我們重視和使用好。

角色許可權（Role）和系統許可權（System）的幾個澄清實驗

相關文章