Изучаем метки доступа к строкам: задание свойств столбца доступа в таблице Oracle
Страница 3. Кто и как может изменять метки секретности

Кто и как может изменять метки секретности

Умолчательная реакция на изменение метки обычным пользователем

Метку секретности строки можно поменять, и администратор (пользователь LBACSYS) это уже делал. А вот что произойдет, если поменять значение метки попробуют «обычные» пользователи:

CONNECT / AS SYSDBA

GRANT INSERT, UPDATE, DELETE ON scott.phone TO minimal;

SQL> CONNECT head/head
Соединено.
SQL> @updateallen OPEN

1 строка обновлена.

SQL> @updateallen LIMITED

1 строка обновлена.

SQL> @updateallen LIMITED

1 строка обновлена.

SQL> @updateallen OPEN

1 строка обновлена.

Вывод: пользователь HEAD беспрепятственно изменяет метку строки, как ему угодно. А пользователь EMPLOYEE ?

SQL> CONNECT employee/employee
Соединено.
SQL> @updateallen OPEN

1 строк обновлено.

SQL> @updateallen OPEN

1 строк обновлено.

SQL> @updateallen LIMITED

1 строк обновлено.

SQL> @updateallen LIMITED

0 строк обновлено.

SQL> @updateallen OPEN

0 строк обновлено.

Очевидно, как только метка становится LIMITED, пользователь EMPLOYEE теряет возможность ее изменять, а когда значение метки - OPEN, он такую возможность имеет. Он даже может сделать строку более секретной, но тогда потеряет к ней доступ.

Запрет делать то, результат чего не увидишь

Ситуация напоминает выводимую таблицу, view, где обладатель права изменять view может добавить через view в базовую таблицу строки, которые сам через view не увидит. Воспрепятствовать этому способно специальное ограничение целостности WITH CHECK OPTION. А можно ли здесь запретить выводить строки из зоны собственной видимости ? Да: для этого в параметре TABLE_OPTIONS достаточно указать специальный режим CHECK_CONTROL использования метки в таблице PHONE. Выдаем в SQL*Plus:

@phonepolicyoptions 'read_control, check_control'

SQL> CONNECT employee/employee
Connected.
SQL> @updateallen OPEN

1 row updated.

SQL> @updateallen LIMITED
UPDATE scott.phone
 *
ERROR at line 1:
ORA-28115: policy with check option violation

SQL> @updateallen OPEN

1 row updated.

SQL> CONNECT head/head 
Connected.
SQL> @updateallen OPEN

1 row updated.

SQL> @updateallen LIMITED

1 row updated.

SQL> @updateallen LIMITED

1 row updated.

SQL> @updateallen OPEN

1 row updated.

Жесткий запрет на изменение метки

Другой режим использования метки в TABLE_OPTIONS еще более ограничителен. Он вовсе запрещает изменять значение метки, не важно в сторону ли увеличения или понижения ее секретности. Выдадим:

@phonepolicyoptions 'read_control, label_update'

Проверяем:

SQL> CONNECT employee/employee
Connected.
SQL> @updateallen OPEN

1 row updated.

SQL> @updateallen LIMITED
UPDATE scott.phone
 *
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
... ... ... ...

SQL> @updateallen OPEN

1 row updated.

SQL> CONNECT head/head
Connected.
SQL> @updateallen OPEN

1 row updated.

SQL> @updateallen LIMITED
UPDATE scott.phone
 *
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
... ... ... ...

Пример пока лишь доказывает, что метку нельзя сделать более «секретной». Но возможно, разрешено «играть на понижение» секретности ? Проверям снова:

CONNECT lbacsys/lbacsys
Connected.
SQL> @updateallen LIMITED

1 row updated.

SQL> CONNECT head/head
Connected.
SQL> @updateallen LIMITED

1 row updated.

SQL> @updateallen OPEN
UPDATE scott.phone
*
ERROR at line 1:
ORA-12406: unauthorized SQL statement for policy EMPSEC_POLICY
... ... ... ...

Что и требовалось доказать: режим LABEL_UPDATE использования метки, заданный для таблицы PHONE в рамках нашей политики, не позволяет обычным пользователям изменять значение меток доступа в строках таблицы.