Oracle 視圖權限傳遞機制：WITH GRANT OPTION 缺失導致 ORA-01031 完整分析

三個擁有 DBA 角色的用戶 TEST1/TEST2/TEST3，TEST1 建表授權 TEST2，TEST2 建視圖授權 TEST3，TEST3 查詢視圖卻報 ORA-01031: 權限不足。本文深度解析視圖權限的兩大核心規則：角色權限屏蔽、授權鏈路完整性 (WITH GRANT OPTION)，並給出修正方案。

一、場景重現

-- TEST1
CREATE TABLE t1 AS SELECT * FROM all_objects;
GRANT SELECT ON t1 TO test2;  -- 缺少 WITH GRANT OPTION

-- TEST2
CREATE VIEW v_t1 AS SELECT * FROM test1.t1;
GRANT SELECT ON v_t1 TO test3;

-- TEST3 (擁有 DBA 角色)
SELECT * FROM test2.v_t1 WHERE rownum < 1;
-- ORA-01031: insufficient privileges

二、核心規則解析

規則 1：視圖屏蔽角色權限 (Definer's Rights 模型)

• 視圖執行時使用**定義者 (TEST2) 的權限**，而非調用者 (TEST3) 的權限。
• 即使 TEST3 有 DBA 角色 / SELECT ANY TABLE 系統權限，**視圖內部引用的基表權限必須由定義者顯式擁有**，角色權限不生效。
• 若 TEST1 未授權 TEST2，TEST2 建視圖時即會報 ORA-01031。

規則 2：授權鏈路需 WITH GRANT OPTION

• TEST2 將視圖 v_t1 授權 TEST3，實質上是**轉授** TEST1 表 t1 的查詢權限給 TEST3。
• Oracle 要求：轉授者 (TEST1) 必須在原授權時指定 WITH GRANT OPTION，否則鏈路中斷。
• 本案例中，TEST1 僅 GRANT SELECT ON t1 TO test2，**缺少 WITH GRANT OPTION**，導致 TEST2 無法轉授，TEST3 查詢失敗。

三、修正方案

-- TEST1 執行：補授 WITH GRANT OPTION
GRANT SELECT ON t1 TO test2 WITH GRANT OPTION;

執行後，TEST3 即可正常查詢 test2.v_t1。

四、延伸：UPDATE/DELETE/INSERT 同理

視圖的 DML 權限轉授同樣要求基表授權時帶 WITH GRANT OPTION。若視圖不可更新 (含聚合、JOIN、DISTINCT 等)，則無法授予 DML 權限。

五、特殊現象：系統權限 vs 物件權限優先級

測試發現：若 TEST2 **未顯式授權** 視圖給 TEST3，但 TEST3 擁有 SELECT ANY TABLE 或 DBA，則查詢**不報錯** (系統權限生效)。但一旦**顯式授權物件權限** (GRANT SELECT ON v_t1 TO test3)，物件權限檢查優先，**且不與系統權限合併評估**，導致因缺少 WITH GRANT OPTION 而失敗。

→ 結論：顯式物件授權會「蓋過」系統權限，且嚴格檢查授權鏈路。生產環境建議：要么全靠系統權限 (不授物件權限)，要么完整建立物件授權鏈路 (含 WITH GRANT OPTION)，避免混用產生不可預期行為。

六、最佳實踐

1. 建視圖的 Schema (TEST2) 應為應用專用帳號，非 DBA。
2. 基表授權視圖擁有者時，**預設加 WITH GRANT OPTION** (除非明確不允許轉授)。
3. 視圖授權應用角色/用戶時，同步檢查基表授權鏈路完整性。
4. 文檔化每個視圖的基表依賴與授權路徑，納入權限矩陣管理。