Oracle用戶授權看起來是很簡單的事情，但是如果做過頭了，很可能引發大問題。所以我們在做Oracle用戶授權時，需要謹慎又謹慎。

看到有人提問關于Oracle用戶授權的問題. 不由得想多說幾句. Oracle 9i 以及以下版本的數據庫,默認的數據庫角色有些不太合理的地方. DBA 管理的過程中,如果不太注意的話,可能會帶來麻煩或者潛在的隱憂. 比如最常見的 CONNECT 角色.

User => FOO has been granted the following privileges 
====================================================================  
        ROLE => CONNECT which contains =>  
        SYS PRIV => ALTER SESSION   grantable => NO 
        SYS PRIV => CREATE CLUSTER   grantable => NO 
        SYS PRIV => CREATE DATABASE LINK  grantable => NO 
        SYS PRIV => CREATE SEQUENCE   grantable => NO 
        SYS PRIV => CREATE SESSION   grantable => NO 
        SYS PRIV => CREATE SYNONYM   grantable => NO 
        SYS PRIV => CREATE TABLE   grantable => NO 
        SYS PRIV => CREATE VIEW   grantable => NO 

這里面的 ALTER SESSION 就是一個問題. 惡意的用戶很容易利用這個權限給系統帶來麻煩.舉兩個例子,一個是 修改當前 Session 的 cursor_sharing 參數值為 FORCE ,然后提交可觸發 Oracle Bug 的查詢(cursor_sharing 在 FORCE 模式下 Bug 很多) , 很容易讓數據庫崩潰. 或者惡意用戶提交 alter session set hash_area_size ... 的修改語句, 給自己設定一個超大的 HASH_AREA_SIZE , 再提交一定的查詢,也會給系統性能造成很糟糕的影響.

這個 CONNECT 角色在 Oracle 10g 中已經修改了,只有 create session 的權限.

再來一個角色的問題. 比如 REOURCE 角色, 包含的權限如下所示:

User => FOO has been granted the following privileges 
====================================================================  
        ROLE => RESOURCE which contains =>  
        SYS PRIV => CREATE CLUSTER    grantable => NO 
        SYS PRIV => CREATE INDEXTYPE   grantable => NO 
        SYS PRIV => CREATE OPERATOR    grantable => NO 
        SYS PRIV => CREATE PROCEDURE   grantable => NO 
        SYS PRIV => CREATE SEQUENCE    grantable => NO 
        SYS PRIV => CREATE TABLE    grantable => NO 
        SYS PRIV => CREATE TRIGGER    grantable => NO 
        SYS PRIV => CREATE TYPE    grantable => NO 
        SYS PRIV => UNLIMITED TABLESPACE   grantable => NO 

注意是包含 UNLIMITED TABLESPACE 權限的(實際上是隱含的一個權限,Oracle為什么這樣做,沒有明確的文檔說明,在 10g 中為了向后兼容,也是這樣的.), 惡意用戶利用這個造成麻煩很容易:在 SYSTEM 建立一個足夠大的表即可讓數據庫宕機.

所以,DBA 在給用戶授權的時候還是謹慎為是,建議利用"最小授權原則", 只給用戶必須的權限.