Oralce public access 許可權的回收後影響分析
公司近期要回收賦予public的許可權,因為以前的表一幫都賦予了 grant select on table_name to public.
這樣是很不安全的,但是回收會引起程式出錯,或不能直接訪問表. 所以寫了程式來進行分析:
主要針對三種情況:
1. 直接被賦予select any table 許可權的使用者是不受影響的.
2. 透過role具有select any table 的許可權,如果是select table是沒有問題的,但是如果在物件,如package, view 中引用物件,就會出錯.
3. 我們已經具有的一個select 的role,可以查詢所有應用schema 的表, 這種情況的分析和情況2類似.
所以按以下步驟來處理:
a ) 寫了以下函式進行判斷和分析.
CREATE OR REPLACE FUNCTION JUDGEPUBLIC(P_USERNAME DBA_USERS.USERNAME%TYPE) RETURN VARCHAR2 IS
L_RESULT VARCHAR2(200) := ' ';
LN_PRI_SELECT_ANY NUMBER(1) := 0;
LN_APP_SELECT NUMBER(1) := 0;
BEGIN
--判斷是否具有SELECT ANY TABLE 的許可權
SELECT COUNT(A.PRIVILEGE)
INTO LN_PRI_SELECT_ANY
FROM DBA_SYS_PRIVS A
WHERE A.GRANTEE=P_USERNAME
AND A.PRIVILEGE='SELECT ANY TABLE' ;
IF LN_PRI_SELECT_ANY > 0 THEN
L_RESULT:='N: 具有SELECT ANY TABLE 的許可權,不影響';
RETURN(L_RESULT);
END IF;
--判斷它是否屬於一個ROLE, 而這個ROLE又具有SELECT ANY TABLE 的許可權,
SELECT COUNT(*)
INTO LN_PRI_SELECT_ANY
FROM DBA_SYS_PRIVS T
WHERE T.GRANTEE IN
(SELECT A.GRANTED_ROLE
FROM DBA_ROLE_PRIVS A
START WITH A.GRANTEE=P_USERNAME --遞迴查詢,因為ROLE可能會層層巢狀
CONNECT BY PRIOR A.GRANTED_ROLE=A.GRANTEE )
AND PRIVILEGE IN ('SELECT ANY TABLE') ;
IF LN_PRI_SELECT_ANY > 0 THEN
L_RESULT:='N: 透過ROLE具有SELECT ANY TABLE 的許可權, 如果不透過物件引用,則不影響;否則,則有影響';
RETURN(L_RESULT);
END IF;
--判斷此帳號是否屬於直接屬於ROLE APP_SELECT, 或透過別的ROLE間接屬於ROLE
SELECT COUNT(*)
INTO LN_APP_SELECT
FROM
(SELECT *
FROM DBA_ROLE_PRIVS A
START WITH A.GRANTEE=P_USERNAME --遞迴查詢,因為ROLE可能會層層巢狀
CONNECT BY PRIOR A.GRANTED_ROLE=A.GRANTEE)
WHERE GRANTED_ROLE='APP_SELECT';
IF LN_APP_SELECT >0 THEN
L_RESULT:='N: 屬於ROLE APP_SELECT, 如果不透過物件引用,則不影響;否則,則有影響';
RETURN(L_RESULT);
END IF;
--如果既不具有select any table 許可權,也沒有透過role具有select any table 許可權, 同時不直接和間接屬於APP_SELECT 角色
L_RESULT:='Y: 既不具有select any table 許可權,也沒有透過role具有select any table 許可權, 同時不直接和間接屬於APP_SELECT 角色,有影響';
RETURN L_RESULT;
END JUDGEPUBLIC;
/
b) 執行SQL得到分析結果:
SELECT Q.username,judgepublic(P_USERNAME => USERNAME) impact FROM DBA_USERS Q ORDER BY 1;
c) 結果如下:
username impact
AGT N: 透過ROLE具有SELECT ANY TABLE 的許可權, 如果不透過物件引用,則不影響;否則,則有影響
ANONYMOUS Y: 既不具有select any table 許可權,也沒有透過role具有select any table 許可權, 同時不直接和間接屬於WII_SELECT 角色,有影響
APEX_030200 Y: 既不具有select any table 許可權,也沒有透過role具有select any table 許可權, 同時不直接和間接屬於WII_SELECT 角色,有影響
A_TEST N: 具有SELECT ANY TABLE 的許可權,不影響
BIGDATA N: 具有SELECT ANY TABLE 的許可權,不影響
這樣是很不安全的,但是回收會引起程式出錯,或不能直接訪問表. 所以寫了程式來進行分析:
主要針對三種情況:
1. 直接被賦予select any table 許可權的使用者是不受影響的.
2. 透過role具有select any table 的許可權,如果是select table是沒有問題的,但是如果在物件,如package, view 中引用物件,就會出錯.
3. 我們已經具有的一個select 的role,可以查詢所有應用schema 的表, 這種情況的分析和情況2類似.
所以按以下步驟來處理:
a ) 寫了以下函式進行判斷和分析.
CREATE OR REPLACE FUNCTION JUDGEPUBLIC(P_USERNAME DBA_USERS.USERNAME%TYPE) RETURN VARCHAR2 IS
L_RESULT VARCHAR2(200) := ' ';
LN_PRI_SELECT_ANY NUMBER(1) := 0;
LN_APP_SELECT NUMBER(1) := 0;
BEGIN
--判斷是否具有SELECT ANY TABLE 的許可權
SELECT COUNT(A.PRIVILEGE)
INTO LN_PRI_SELECT_ANY
FROM DBA_SYS_PRIVS A
WHERE A.GRANTEE=P_USERNAME
AND A.PRIVILEGE='SELECT ANY TABLE' ;
IF LN_PRI_SELECT_ANY > 0 THEN
L_RESULT:='N: 具有SELECT ANY TABLE 的許可權,不影響';
RETURN(L_RESULT);
END IF;
--判斷它是否屬於一個ROLE, 而這個ROLE又具有SELECT ANY TABLE 的許可權,
SELECT COUNT(*)
INTO LN_PRI_SELECT_ANY
FROM DBA_SYS_PRIVS T
WHERE T.GRANTEE IN
(SELECT A.GRANTED_ROLE
FROM DBA_ROLE_PRIVS A
START WITH A.GRANTEE=P_USERNAME --遞迴查詢,因為ROLE可能會層層巢狀
CONNECT BY PRIOR A.GRANTED_ROLE=A.GRANTEE )
AND PRIVILEGE IN ('SELECT ANY TABLE') ;
IF LN_PRI_SELECT_ANY > 0 THEN
L_RESULT:='N: 透過ROLE具有SELECT ANY TABLE 的許可權, 如果不透過物件引用,則不影響;否則,則有影響';
RETURN(L_RESULT);
END IF;
--判斷此帳號是否屬於直接屬於ROLE APP_SELECT, 或透過別的ROLE間接屬於ROLE
SELECT COUNT(*)
INTO LN_APP_SELECT
FROM
(SELECT *
FROM DBA_ROLE_PRIVS A
START WITH A.GRANTEE=P_USERNAME --遞迴查詢,因為ROLE可能會層層巢狀
CONNECT BY PRIOR A.GRANTED_ROLE=A.GRANTEE)
WHERE GRANTED_ROLE='APP_SELECT';
IF LN_APP_SELECT >0 THEN
L_RESULT:='N: 屬於ROLE APP_SELECT, 如果不透過物件引用,則不影響;否則,則有影響';
RETURN(L_RESULT);
END IF;
--如果既不具有select any table 許可權,也沒有透過role具有select any table 許可權, 同時不直接和間接屬於APP_SELECT 角色
L_RESULT:='Y: 既不具有select any table 許可權,也沒有透過role具有select any table 許可權, 同時不直接和間接屬於APP_SELECT 角色,有影響';
RETURN L_RESULT;
END JUDGEPUBLIC;
/
b) 執行SQL得到分析結果:
SELECT Q.username,judgepublic(P_USERNAME => USERNAME) impact FROM DBA_USERS Q ORDER BY 1;
c) 結果如下:
username impact
AGT N: 透過ROLE具有SELECT ANY TABLE 的許可權, 如果不透過物件引用,則不影響;否則,則有影響
ANONYMOUS Y: 既不具有select any table 許可權,也沒有透過role具有select any table 許可權, 同時不直接和間接屬於WII_SELECT 角色,有影響
APEX_030200 Y: 既不具有select any table 許可權,也沒有透過role具有select any table 許可權, 同時不直接和間接屬於WII_SELECT 角色,有影響
A_TEST N: 具有SELECT ANY TABLE 的許可權,不影響
BIGDATA N: 具有SELECT ANY TABLE 的許可權,不影響
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/674865/viewspace-1225045/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 物件許可權的回收物件
- 許可權授予、回收命令
- public, private, protected 訪問許可權訪問許可權
- 擁有GRANT ANY OBJECT PRIVILEGE許可權時的許可權回收Object
- public_html的許可權問題(轉)HTML
- DB2 public許可權相關DB2
- 【許可權管理】Oracle中檢視、回收使用者許可權Oracle
- unlimited tablespace許可權的授予和回收MIT
- 使用者有connect,resource,dba角色許可權後回收dba許可權導致無UNLIMITED TABLESPACE許可權造成業務中斷MIT
- GitHub的Repository許可權將public轉為privateGithub
- oracle受權與回收許可權grant和revokeOracle
- Oracle的物件許可權、角色許可權、系統許可權Oracle物件
- oracle常見受權與回收許可權 grant和revokeOracle
- 資料分析的許可權控制
- Linux讀寫執行許可權對目錄和檔案的影響Linux
- Django(63)drf許可權原始碼分析與自定義許可權Django原始碼
- Oracle使用者訪問許可權與PUBLIC角色的關係Oracle訪問許可權
- oralce關於使用者和許可權的一些命令(轉)
- mysql操作命令梳理(4)-grant授權和revoke回收許可權MySql
- AIX 的許可許可權(轉)AI
- 許可權之選單許可權
- Oracle中定義者許可權和呼叫者許可權案例分析Oracle
- PostgreSQL物件許可權如何在後設資料中獲取-許可權解讀、定製化匯出許可權SQL物件
- Linux 下程式許可權分析Linux
- 如何用 Vue 實現前端許可權控制(路由許可權 + 檢視許可權 + 請求許可權)Vue前端路由
- linux 檔案許可權 s 許可權和 t 許可權解析Linux
- ORALCE 的AUDIT 以及開啟AUDIT對REDO 的影響
- 授權物件許可權後的授權者顯示問題物件
- 塗抹MySQL--第5章 MySQL資料庫中的許可權體系 - 5.2許可權授予與回收(3)MySql資料庫
- 塗抹MySQL--第5章 MySQL資料庫中的許可權體系 - 5.2許可權授予與回收(2)MySql資料庫
- 塗抹MySQL--第5章 MySQL資料庫中的許可權體系 - 5.2許可權授予與回收(1)MySql資料庫
- MongoDB 4.0檢視,更新和回收角色許可權步驟MongoDB
- Linux-許可權管理(ACL許可權)Linux
- 【自然框架】許可權的視訊演示(二):許可權到欄位、許可權到記錄框架
- [譯]SQL Server分析服務的許可權配置SQLServer
- Vue2.0 + ElementUI 手寫許可權管理系統後臺模板(二)——許可權管理VueUI
- Android系統許可權和root許可權Android
- django開發之許可權管理(一)——許可權管理詳解(許可權管理原理以及方案)、不使用許可權框架的原始授權方式詳解Django框架