Menu de navegação

[DBA_LUCASParticipante]

Boa tarde a todos !

Estou com o seguinte problema , aqui na minha empresa estou selecionando determinadas permissões para os usuarios pois estava uma bagunça , portanto preciso saber como dar permissão para os usuarios verificarem o plano de execução para pegarem dados sobre o custo dos selects…

obrigado ;

[DBA_LUCASParticipante]

Atualmente uso as seguintes permissões:

GRANT ALTER DATABASE TO USUARIO;
GRANT DEBUG ANY PROCEDURE TO USUARIO;
GRANT CREATE ANY INDEX TO USUARIO;
GRANT ALTER ANY INDEX TO USUARIO;
GRANT DROP ANY INDEX TO USUARIO;
GRANT CREATE ANY JOB TO USUARIO;
GRANT CREATE MATERIALIZED VIEW TO USUARIO;
GRANT DROP ANY MATERIALIZED VIEW TO USUARIO;
GRANT CREATE PROCEDURE TO USUARIO;
GRANT ALTER ANY PROCEDURE TO USUARIO;
GRANT DROP ANY PROCEDURE TO USUARIO;
GRANT EXECUTE ANY PROCEDURE TO USUARIO;
GRANT CREATE SEQUENCE TO USUARIO;
GRANT ALTER ANY SEQUENCE TO USUARIO;
GRANT DROP ANY SEQUENCE TO USUARIO;
GRANT SELECT ANY SEQUENCE TO USUARIO;
GRANT CREATE SYNONYM TO USUARIO;
GRANT CREATE TABLE TO USUARIO;
GRANT ALTER ANY TABLE TO USUARIO;
GRANT DELETE ANY TABLE TO USUARIO;
GRANT DROP ANY TABLE TO USUARIO;
GRANT INSERT ANY TABLE TO USUARIO;
GRANT SELECT ANY TABLE TO USUARIO;
GRANT UPDATE ANY TABLE TO USUARIO;
GRANT CREATE TRIGGER TO USUARIO;
GRANT ALTER ANY TRIGGER TO USUARIO;
GRANT DROP ANY TRIGGER TO USUARIO;
GRANT CREATE TYPE TO USUARIO;
GRANT ALTER ANY TYPE TO USUARIO;
GRANT DROP ANY TYPE TO USUARIO;
GRANT EXECUTE ANY TYPE TO USUARIO;
GRANT CREATE VIEW TO USUARIO;
GRANT DROP ANY VIEW TO USUARIO;
GRANT CREATE SESSION TO USUARIO;
GRANT UNLIMITED TABLESPACE TO USUARIO;
GRANT SELECT ON V_$SESSION TO USUARIO;

[felipegParticipante]

Amigo,

Se for pra permitir que eles possam usar o “SET AUTOTRACE” é só seguir a receita abaixo:

OBS: Usei o %ORACLE_HOME% (windows), se for linux é só trocar pra $ORACLE_HOME e se certificar que a variável está definida com o caminho certo.


Logue como sys e execute os comandos na ordem abaixo

@%ORACLE_HOME%/rdbms/admin/utlxplan.sql
create or replace public synonym plan_table for plan_table;
grant all on plan_table to public;
@%ORACLE_HOME%/sqlplus/admin/plustrce.sql
grant plustrace to public;

Agora é só logar com o usuário normal, executar o “SET AUTOTRACE ON” e dar um select pra testar.

Atenciosamente,
Felipe.

[rmanParticipante]

@DBA_LUCAS


GRANT SELECT ANY TABLE TO USUARIO;
GRANT INSERT ANY TABLE TO USUARIO;
GRANT UPDATE ANY TABLE TO USUARIO;
GRANT DELETE ANY TABLE TO USUARIO;


Isso não está liberando SELECT, INSERT, UPDATE, DELETE para o usuário mexer em qualquer tabela de qualquer usuário ?

Isso não é perigoso ? 😯

Eu costumo liberar as roles CONNECT e RESOURCE, e mais algumas coisas, isso já é suficiente para o desenvolvedor.

[DBA_LUCASParticipante]

Na verdade nunca trabalhei com permissões , agora que estou implantando esta política de permissões , portanto , qualquer ajuda é bem vinda . Mas com conect e resource o programador consegue dar select,insert,delete na base corrente ???

[felipegParticipante]

Não.

Você terá que liberar as permissões para os não-donos dos objetos um por um.

Minha sugestão é que você crie uma ROLE com as permissões que você precisa e depois, a cada criação de novo acesso, liberasse as ROLES necessárias ao invés de dar GRANT de objeto por objeto para cada usuário.

Mas isso depende da sua estrutura da aplicação e da forma de acesso ao banco.

Sugiro dar uma boa lida nessa parte antes de sair implementando.

http://download.oracle.com/docs/cd/B193 … musers.htm

Atenciosamente,
Felipe.

[rmanParticipante]

@DBA_LUCAS

Como o seu sistema de produção trabalha ? Utiliza apenas um usuário do banco ou cada usuário do sistema possui um usuário no banco ? O desenvolvedor possui um usuário próprio ou ele utiliza o mesmo usuário do banco que o sistema utiliza ?

Vou arriscar um chute, provavelmente o sistema de produção possui apenas um usuário no banco e o desenvolvedor utiliza esse usuário. Neste cenário de permissão de:

GRANT CONNECT TO USUARIO;
GRANT RESOURCE TO USUARIO;

GRANT CREATE VIEW TO USUARIO; — se é utilizado view
GRANT CREATE SYNONYM TO USUARIO; — se é utilizado synonym

A ROLE CONNECT possui a seguinte permissão:
CREATE SESSION

A ROLE RESOURCE possui as seguintes permissões:
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE

O dono do objeto pode tudo, se você for trabalhar com objetos de outros usuário ai sim é necessário dar permissão objeto por objeto assim como foi dito pelo felipeg.

[Regis AraujoParticipante]

Opa.. Bom dia..!

Lucas.. vc quer apenas verificar permissões para dar explain plan??

Bom, depende de quais os comandos serão gerados plano de execução..

Pois no Oracle para um usuário gerar o plano de execução de um comando.. ele precisa ter o acesso específico do comando..

Ou seja..!

Se o usuário precisar gerar um plano de um select.. ele precisará ter permissão de “select” nas tabelas contidas no select..

Se o plano for em um update|delete|insert o usuário precisará ter permissão de update|delete|insert …

Cara.. Primeiro verifica direito como está seu ambiente..

Existe 1 schema proprietário das tabelas e outros logins que acessar os objetos de um schema específico?

Se existe mais de um login para acessar os objetos de um schema.. qual a finalidade te ter tantos?

Outra coisa.. faça como o Felipe falou.. de grants por roles…
Uma dica é:

Crie 2 roles.. uma com grant de CONSULTA e outra com grant de update/delete/insert nas tabelas.. e de grant destas roles para os objetos que eles realmente precisam.. pois em alguns objetos o login específico não irá fazer insert|update|delete, estes comandos serão realizados atraves de procedures|triggers|functions..

O(s) logins terão apenas permissão para conectar e dar select na base.. se precisarem fazer alguma alteração.. será através de procedures|functions.. e em alguns casos bem determinados eles terão grant da role q tem grant de insert|update|delete …

Bom.. acho q é isto..!!

Abraços..!

[DBA_LUCASParticipante]

Primeiramente muito obrigado a todos pela ajuda , vou tentar explicar como é meu ambiente:

Tenho um servidor para os desenvolvedores , neste servidor tenho +- 30 schemas , mas com possibilidade de aumentar , logo que meu servidor antigo tinha 160 schemas …. cada desenvolvedor conecta no schema com o usuario do proprio schema ,

ex: SCHEMA FIAT o desenvolvedor conecta como FIAT/SENHA@INSTANCIA ….

MInha duvida é como administrar permissões para os schemas após cria-los …. Preciso que os desenvolvedores tenham permissão de SELECT,INSERT,UPDATE,DELETE,CREATE,ALTER,EXEC PROCEDURE,CREATE PROCEDURE,ALTER PROCEDURE,CREATE VIEW,ALTER VIEW,ETC….

[rmanParticipante]

@DBA_LUCAS

Se o desenvolvedor sempre for utilizar o dono do schema, as permissões que eu passei já são suficientes.

[felipegParticipante]

Lucas

Seguinte, temos ai um if bem legal

Se o schema de acesso para os usuários for o dono dos objetos, dê apenas as permissões citadas pelo rman.

Senão, dê as permissões citadas por ele e depois leia o que eu e o Thunder_catz escrevemos para definir o resto.

Se tiver alguma dúvida é só avisar.

Boa sorte!
Atenciosamente,
Felipe.

[Autor]

Posts