2016-04-24 2 views
0

1/Насколько мне известно, прямые privilege грант и ROLE грант и PUBLIC грант являются независимыми, то есть все 3 могут нести ту же привилегию. Отмена от одного не мешает этой привилегии по-прежнему оставаться у пользователя. Значение, если мыПрямые привилегии и ВСЕ ПРИВИЛЕГИИ против ролей против PUBLIC

GRANT SELECT ON T TO userA 
GRANT SELECT ON T TO roleA; GRANT roleA to userA 
GRANT SELECT on T TO PUBLIC 

Аннулирование один или два из 3-х грантов оставляет ПользовательА с SELECT привилегий. Как насчет ALL PRIVILEGES, он перекрывается с любым из этих 3 зонами? Если у нас есть 3 гранта выше и следующие

GRANT ALL PRIVILEGES on T to userA; 

, а затем мы

REVOKE ALL PRIVILEGES on T to userA; 

, который один из 3-х грантов будут дополнительно удалены? Одинаково ли оно относится к привилегиям системных привилегий и объектов?

2/Есть GRANT ANY PRIVILEGE и GRANT ALL PRIVILEGE*S*. Они одинаковы ?

ответ

0

В соответствии с документами «Oracle Database предоставляет ярлык« ВСЕ ПРИВИЛЕГИИ »для предоставления всех системных привилегий, перечисленных в таблице 18-1, за исключением привилегии SELECT ANY DICTIONARY». Ваши примеры не являются системными привилегиями, поэтому нет перекрытия. https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_9013.htm

Что касается GRANT ANY PRIVILEGE, это предоставляет пользователю возможность в свою очередь предоставлять системные привилегии другим пользователям. Например:

[email protected]> GRANT GRANT ANY PRIVILEGE to some_user; 
grant succeeded 

повторно подключиться как some_user. Теперь этот пользователь может передать системные гранты some_other_user.

[email protected]> GRANT COMMENT ANY TABLE to some_other_user; 
grant succeeded 

Это, кажется, как привилегия, которую вы хотите использовать, когда вы хотите, чтобы дать пользователю частичные привилегии DBA и следует использовать с осторожностью.

В отличие ВСЕ ЛЬГОТЫ больше похож на макрос, который предоставляет все индивидуальные системные привилегии сразу так

GRANT ALL PRIVILEGES to some_user; 

будет как бег заявления на гранты для всех системных привилегий (и их много):

GRANT ADVISOR TO some_user; 
GRANT ADMINISTER SQL TUNING SET TO some_user; 
GRANT ADMINISTER ANY SQL TUNING SET TO some_user; 
GRANT CREATE ANY SQL PROFILE TO some_user; 
GRANT DROP ANY SQL PROFILE TO some_user; 
GRANT ALTER ANY SQL PROFILE TO some_user; 
etc... 

РЕДАКТИРОВАТЬ: Кроме того, в указанной выше ссылке, под grant_object_privileges раздела есть также:

ВСЕ [ЛЬГОТЫ]

Укажите ALL, чтобы предоставить все привилегии для объекта, который вы имеете был предоставлен с GRANT OPTION. Пользователь, которому принадлежит схема , содержащая объект, автоматически имеет все права на объекте с ОПЦИИ ГАРАНТИИ. Ключевое слово PRIVILEGES предоставляется для смысловой четкости и является необязательным.

Если вы что-то вроде

GRANT ALL PRIVILEGES on some_table TO some_user; 

, что пользователь получает все эти привилегии таблицы (по крайней мере, это список я получаю в 12с):

FLASHBACK 
DEBUG 
QUERY REWRITE 
ON COMMIT REFRESH 
READ 
REFERENCES 
UPDATE 
SELECT 
INSERT 
INDEX 
DELETE 
ALTER 

Для последовательностей вы получите :

SELECT 
ALTER 

(И другие типы объектов будут иметь r собственный).

Таким образом, это как ВСЕ ПРИВИЛЕГИИ для системных привилегий, поскольку это ярлык для предоставления всех прав объекта для указанного типа объекта; нет ни одной привилегии «ВСЕ ПРИВИЛЕГИИ», которую вы получаете. Для таблиц это как набрав в заявлениях о предоставлении гранта 12 льгот, перечисленных выше:

GRANT FLASHBACK on ... 
GRANT DEBUG on ... 
GRANT QUERY REWRITE on ... 

Каждый из этих льгот могут быть индивидуально отменены. Так что если вы сделали:

REVOKE INSERT, UPDATE, DELETE on some_table FROM some_user; 

у вас все еще есть 9 других привилегий из приведенных выше привилегий.

Если вы используете «ВСЕ ЛЬГОТЫ» с REVOKE:

REVOKE ALL PRIVILEGES on some_table FROM some_user; 

заберет какую бы то ни привилегию таблицы some_user была оставшаяся на some_table в приведенном выше списке.

Таким образом, чтобы сделать длинную историю больше, вот SQL пример, чтобы показать ответ на исходный вопрос (владелец таблицы Т USERT):

SQL> create table t (a varchar2(1)); 

Table created. 

SQL> grant select on t to userA; 

Grant succeeded. 

SQL> select grantor 
    2  , grantee 
    3  , table_schema 
    4  , table_name 
    5  , privilege 
    6 from all_tab_privs 
    7 where table_name = 'T' 
    8 order by grantee; 

GRANTOR GRANTEE TABLE_SCHEMA TABLE_NAME PRIVILEGE 
---------- ---------- ------------ ---------- -------------------- 
USERT  USERA  USERT  T   SELECT 

SQL> 
SQL> grant select on t to roleA; 

Grant succeeded. 

SQL> select grantor 
    2  , grantee 
    3  , table_schema 
    4  , table_name 
    5  , privilege 
    6 from all_tab_privs 
    7 where table_name = 'T' 
    8 order by grantee; 

GRANTOR GRANTEE TABLE_SCHEMA TABLE_NAME PRIVILEGE 
---------- ---------- ------------ ---------- -------------------- 
USERT  ROLEA  USERT  T   SELECT 
USERT  USERA  USERT  T   SELECT 

SQL> grant select on t to public; 

Grant succeeded. 

SQL> select grantor 
    2  , grantee 
    3  , table_schema 
    4  , table_name 
    5  , privilege 
    6 from all_tab_privs 
    7 where table_name = 'T' 
    8 order by grantee; 

GRANTOR GRANTEE TABLE_SCHEMA TABLE_NAME PRIVILEGE 
---------- ---------- ------------ ---------- -------------------- 
USERT  PUBLIC  USERT  T   SELECT 
USERT  ROLEA  USERT  T   SELECT 
USERT  USERA  USERT  T   SELECT 

SQL> grant all privileges on t to userA; 

Grant succeeded. 

SQL> select grantor 
    2  , grantee 
    3  , table_schema 
    4  , table_name 
    5  , privilege 
    6 from all_tab_privs 
    7 where table_name = 'T' 
    8 order by grantee; 

GRANTOR GRANTEE TABLE_SCHEMA TABLE_NAME PRIVILEGE 
---------- ---------- ------------ ---------- -------------------- 
USERT  PUBLIC  USERT  T   SELECT 
USERT  ROLEA  USERT  T   SELECT 
USERT  USERA  USERT  T   INDEX 
USERT  USERA  USERT  T   INSERT 
USERT  USERA  USERT  T   ALTER 
USERT  USERA  USERT  T   SELECT 
USERT  USERA  USERT  T   FLASHBACK 
USERT  USERA  USERT  T   DELETE 
USERT  USERA  USERT  T   REFERENCES 
USERT  USERA  USERT  T   READ 
USERT  USERA  USERT  T   ON COMMIT REFRESH 
USERT  USERA  USERT  T   QUERY REWRITE 
USERT  USERA  USERT  T   DEBUG 
USERT  USERA  USERT  T   UPDATE 

14 rows selected. 

SQL> REVOKE ALL PRIVILEGES on T from userA; 

Revoke succeeded. 

SQL> select grantor 
    2  , grantee 
    3  , table_schema 
    4  , table_name 
    5  , privilege 
    6 from all_tab_privs 
    7 where table_name = 'T' 
    8 order by grantee; 

GRANTOR GRANTEE TABLE_SCHEMA TABLE_NAME PRIVILEGE 
---------- ---------- ------------ ---------- -------------------- 
USERT  PUBLIC  USERT  T   SELECT 
USERT  ROLEA  USERT  T   SELECT 

Так КЕУОКЕ ВСЕ ЛЬГОТЫ командном удалены все прямых грантов в таблице T из userA, но у этого пользователя все равно будут привилегии SELECT через выделение гранта roleA (при условии, что пользователю была предоставлена ​​роль) или выделение гранта для публики.

+0

1. Я не получаю ваш первый балл. По крайней мере, перекрывается между _ALL PRIVILEGES по объекту и прямой привилегией. https://docs.oracle.com/database/121/SQLRF/statements_9021.htm#SQLRF01609 _Revoking привилегии объекта от пользователя: Example_ part. 2. ГРАНТ ВСЕ ПРИВИЛЕГИИ действительно работает над объектами. – Kenny

+0

1. Извините, но я не понимаю, что вы пытаетесь сказать здесь. При отзыве привилегии объекта от пользователя: например, он просто говорит: «Вы можете предоставлять привилегии DELETE, INSERT, READ, SELECT и UPDATE в табличных заказах пользователю hr со следующим утверждением ...» Это не системные привилегии , Системные привилегии перечислены здесь: https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_9013.htm#BABEFFEE Что касается 2) Что вы подразумеваете под «работает над объектами»? Можете ли вы привести пример? –

+0

1 Вы упомянули, что ваши примеры не являются системными привилегиями, поэтому нет перекрытия_. Мой пример - это не системные привилегии, это правильно. И есть перекрытие по моей ссылке: пользователю присваивается _ALL PRIVILEGES_, а _DELETE_ отменяется, все еще оставляя его с другими привилегиями. Это говорит о моей точке зрения, что наложение перекрывается. Если они независимы, произойдет, что пользователь имеет _DELETE_ right и _ALL PRIV_ в одно и то же время, и аннулирование отдельно DELETE оставляет _ALL PRIV_ неповрежденным. – Kenny