Влияет ли отзыв привилегий в Oracle на текущие транзакции, в которых используются эти привилегии?

Question

Мне интересно об этом.Что произойдет, если администратор БД (или лицо, предоставляющее право) аннулирует привилегии пользователя (получателя гранта), в то время как у этого пользователя (получателя гранта) есть текущая транзакция, для которой необходимы эти привилегии (очевидно, когда пользователь (получатель гранта) выдал свою транзакцию,у него были эти привилегии).

Тривиальный сценарий, чтобы сделать это более конкретным: пользователь A предоставляет привилегии пользователю B для вставки данных в таблицу (скажем, Table1) в его (пользователя A) схеме.Пользователь B идет вперед и выдает транзакцию, которая делает много вставок. Пока вставки продолжаются , пользователь A отзывает права на вставку B.Выполняет:

Логически, я бы предположил, что это будет 2, но я не могу найти никакой информации, чтобы подтвердить это в документации Oracle.

Спасибо.

РЕДАКТИРОВАТЬ: Добавление некоторого кода PL / SQL, который я написал, чтобы проверить это (я только собрал это вместе для тестирования этого сценария. Я не знаю PL / SQL, поэтому, пожалуйста, исправьте меня, если я 'м неправильно).

/* Start by testing select privileges */
set serveroutput on;
declare v_emp HR.tempemp%rowtype;
begin
  dbms_output.enable(300000);
  for count_var in 1..200000 loop -- loop a large number of times, and BEFORE the loop exits,
                                  -- revoke the permissions manually from the grantor's session
    select * into v_emp
    from HR.tempemp
    where employee_id = 100;
    dbms_output.put_line(count_var||' '||v_emp.employee_id); -- print count_var so we know which iteration we're in
  end loop;
end;

/* Now test insert privileges */
set serveroutput on;
begin
  dbms_output.enable(300000);
  for count_var in 1..20000000 loop -- loop a large number of times, and BEFORE the loop exits,
                                    -- revoke the permissions manually from the grantor's session
    insert into HR.tempemp
    values(100);
    dbms_output.put_line(count_var); -- print count_var so we know which iteration we're in
  end loop;
end;

Наблюдения:

Answer 1

Это довольно легко проверить: создать пустую таблицу в схеме A. Предоставить привилегию на вставку для схемы B. В схеме B запустите длительный оператор INSERT. Пока он работает, отмените привилегию вставки.

Если вы сделаете это, вы увидите, что вставка продолжается и успешно завершается. Затем, если вы немедленно попытаетесь выполнить его снова, вы получите ORA-01031: insufficient privileges. Поэтому кажется очевидным, что Oracle проверяет привилегии один раз для каждого выполнения оператора. Я просмотрел какую-то документацию и не увидел ничего такого, что прямо указывало бы на это, но кажется, что это самый логичный подход, и эксперимент поддерживает его.

Вы спросили:

"Oracle гарантирует, что вставки не будут остановлены в середине строки?"

Как показано выше, это не очень важно в случае отзыва привилегий; но, по-видимому, стоит более подробно объяснить, как Oracle ведет себя, если в процессе обработки оператора возникает ошибка. Исключая ошибки в Oracle, невозможно, чтобы частичная строка была вставлена ​​и оставлена ​​после ошибки. Если какая-либо ошибка происходит в середине обработки одного оператора SQL, то изменения, сделанные до сих пор этим оператором (не транзакцией), откатываются внутри Oracle. Например, если вы вставляете много строк и сегмент данных должен быть расширен, но нет свободного места, работа, выполненная до настоящего времени текущим оператором, будет откатываться, а затем в коде, выполнившем этот оператор, будет возвращена ошибка , Это не «ненормально завершенный процесс», как обсуждалось в другом потоке, на который вы ссылались; процесс продолжает работать и определяет, как устранить ошибку - он имеет возможность откатить всю транзакцию , но не обязан это делать.

Answer 2

Я только что проверил это по следующему сценарию, вот что произошло:

1-пользователь A создает таблицу.

2-пользователь А предоставляет пользователю Б для вставки.

3-пользователь B вставляет строку, но не COMMIT.

4-пользователь A отзывает пользователя B.

5-пользователь B вставляет строку, , но не может .

5-пользователь B успешно завершает свою работу.