看到 有人提問關(guān)于授權(quán)的問題. 不由得想多說幾句. Oracle 9i 以及以下版本的數(shù)據(jù)庫(kù),默認(rèn)的數(shù)據(jù)庫(kù)角色有些不太合理的地方. DBA 管理的過程中,如果不太注意的話,可能會(huì)帶來麻煩或者潛在的隱憂. 比如最常見的 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 就是一個(gè)問題. 惡意的用戶很容易利用這個(gè)權(quán)限給系統(tǒng)帶來麻煩.舉兩個(gè)例子,一個(gè)是 修改當(dāng)前 Session 的 cursor_sharing 參數(shù)值為 FORCE ,然后提交可觸發(fā) Oracle Bug 的查詢(cursor_sharing 在 FORCE 模式下 Bug 很多) , 很容易讓數(shù)據(jù)庫(kù)崩潰. 或者惡意用戶提交 alter session set hash_area_size ... 的修改語句, 給自己設(shè)定一個(gè)超大的 HASH_AREA_SIZE , 再提交一定的查詢,也會(huì)給系統(tǒng)性能造成很糟糕的影響.
這個(gè) CONNECT 角色在 Oracle 10g 中已經(jīng)修改了,只有 create session 的權(quán)限.
再來一個(gè)角色的問題. 比如 REOURCE 角色, 包含的權(quán)限如下所示:
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 權(quán)限的(實(shí)際上是隱含的一個(gè)權(quán)限,Oracle為什么這樣做,沒有明確的文檔說明,在 10g 中為了向后兼容,也是這樣的.), 惡意用戶利用這個(gè)造成麻煩很容易:在 SYSTEM 建立一個(gè)足夠大的表即可讓數(shù)據(jù)庫(kù)宕機(jī).
posted on 2006-09-07 10:07
七匹狼 閱讀(463)
評(píng)論(0) 編輯 收藏 所屬分類:
oracle