Qual a diferença entre o grant SELECT e READ?

Qual a diferença entre o grant SELECT e READ?

E ai pessoal tudo bem?

No post de hoje será explicado a diferença entre o grant de read e o grant de select.

O grant de read foi incluido na versão 12c release 1, então já faz um bom tempo que temos ele.

As vezes muitas pessoas se perguntam, qual motivo da Oracle incluir um grant de read se já temos o grant de select, antes de ler a documentação e simular a situação eu também tinha essa dúvida.

O que iremos fazer hoje é:

1. Vamos criar um usuário;
2. Criar uma tabela que iremos usar em nossos testes;
3. Conceder grant de select e mostrar o problema que podemos ter;
4. Conceder o grant de read e entender o motivo dele ter sido incluído como uma new feature no Oracle;

Vamos colocar a mão na massa agora.

1 – Criação do usuário

O script abaixo cria o usuário e concede grant de conexão, session, você deve criar esse usuário com um usuário que tenha grant para realizar a criação, no meu exemplo estou usando usuário sys conectado como sysdba no meu pdb.

-- USER SQL
CREATE USER "UHR" IDENTIFIED BY "UHR"  
DEFAULT TABLESPACE "TSDHR01"
TEMPORARY TABLESPACE "TSTEMP01";

-- QUOTAS
ALTER USER "UHR" QUOTA UNLIMITED ON "TSIHR01";
ALTER USER "UHR" QUOTA UNLIMITED ON "TSDHR01";

-- ROLES
GRANT "CONNECT" TO "UHR" ;

-- SYSTEM PRIVILEGES
GRANT CREATE SESSION TO "UHR" ;
GRANT CREATE TABLE TO "UHR" ;

2 – Criar tabela de exemplo

Vamos nos conectar com usuário HR no PDB e não o usuário que acabamos criar “UHR”.

sqlplus HR/HR@192.168.0.22:1521/pdb

Agora vamos utilizar o script abaixo para criarmos a tabela que simularemos os grant’s de read e select.

CREATE TABLE EMPLOYEES_HISTORY 
(
  EMPLOYEES_HISTORY_ID NUMBER(18) NOT NULL 
, EMPLOYEE_ID NUMBER(18) NOT NULL 
, DESCRIPTION VARCHAR2(100) NOT NULL 
, CONSTRAINT EMPLOYEES_HISTORY_PK PRIMARY KEY 
  (
    EMPLOYEES_HISTORY_ID 
  )
  ENABLE 
) 
TABLESPACE TSDHR01;

3 – Grant de SELECT

No script não concedemos nenhum grant para tabela, agora vamos conceder o grant de select para o usuário que criamos UHR. Ainda conectado com usuário HR vamos inserir algumas informações na tabela.

grant SELECT on HR.EMPLOYEES_HISTORY to UHR;
INSERT INTO HR.EMPLOYEES_HISTORY (EMPLOYEES_HISTORY_ID, EMPLOYEE_ID, DESCRIPTION) VALUES ('1', '1', 'teste');
commit;
INSERT INTO HR.EMPLOYEES_HISTORY (EMPLOYEES_HISTORY_ID, EMPLOYEE_ID, DESCRIPTION) VALUES ('2', '2', 'teste 2');
commit;

Vamos nos conectar agora em uma outra seção com usuário UHR que criamos e testar se estamos com o grant de select na tabela.

select * from hr.EMPLOYEES_HISTORY;

Agora chegamos ao ponto para mostrar o motivo de a Oracle ter incluído o grant de read, na seção conectado com usuário UHR iremos fazer um select for update e na seção conectado com usuário HR tentaremos manipular a tabela em quanto o select for update na seção do usuário UHR estiver acontecendo.

--CONECTADO COM USUÁRIO UHR
select * from hr.EMPLOYEES_HISTORY for update;

Na outra seção que estamos conectado com usuário HR, tentaremos fazer um update na tabela.

--CONECTADO COM USUÁRIO HR
update hr.EMPLOYEES_HISTORY set DESCRIPTION = DESCRIPTION;

A imagem abaixo demonstra o usuário UHR (1) gerando um lock devido o select for update (2) na seção de update (5) do usuário HR (3), também é possível ver o lock (6) e ver que apenas o select não gera lock (4).

4 – Grant de READ

Agora vamos remover o grant de select do usuário UHR e conceder o grant de read e simular novamente.

revoke SELECT on HR.EMPLOYEES_HISTORY from UHR; 
grant READ on HR.EMPLOYEES_HISTORY to UHR;

Agora quando o usuário UHR tentar fazer o um select for update ele tomará erro de privilégios insuficientes e com isso um usuário inofensivo com simples grant de select pode gerar um grande problema no banco de dados.

Era isso por hoje, fica a dica, revejam se todos os usuários de seu banco de dados que tenham permissão de select realmente precisam desse grant ou se o grant de read já seria o suficiente.

 Banco de Dados BD GRANT READ GRANT SELECT Oracle READ Read x Select SELECT SELECT FOR UPDATE Você sabia?