- This topic has 6 replies, 2 voices, and was last updated 6 years, 10 months ago by acg1574.
-
AuthorPosts
-
11 de janeiro de 2018 at 3:50 pm #109122acg1574Participant
Pessoal mesmo eu dando grant de select para um certo usuario, ele consegue fazer select em talelas do banco de dados como por exemplo a all_objects, mesmo ela nao estando nos privilegios dele, estranho isso, sabem me dizer o pq ?
11 de janeiro de 2018 at 8:41 pm #109124José Laurindo ChiappaModeratorEntão : na verdade primeiro de tudo veja que os objetos ALL_xxx ** NÂO SÃO TABELAS ** mas sim views, ok ? E no caso, são view INTERNAS DO DATABASE, que justamente por não serem controladas por você NÂO RESPEITAM NEM PRECISAM de GRANTs, certo ??
O segundo ponto é : como Documentado (em https://docs.oracle.com/cd/B28359_01/server.111/b28318/datadict.htm#CNCPT002 no caso do 11g, por exemplo, mas o COnceito vale pra qquer versão) , os objetos particulares (ie, tirando os que pertencem ao DBA) do dicionário de dados são sempre disponíveis para um usuário, o que vai acontecer é que vão parecer VAZIOS pra quem não tem perms/acesso… Isso é algo Óbvio, um usuário PODE a qualquer momento consultar os objetos que lhe pertencem (via USER_OBJECTS) ** E ** pode a qualquer momento consultar os objetos de outros a que tem acesso, via ALL_OBJECTS…E o TERCEIRO PONTO é que há alguns objetos do banco de dados que são PÚBLICOS, ie, TODOS E QUALQUER UM os podem ler : nesse caso, mesmo um usuário o mais zemané, mais lixo possível, VAI TER SIM acesso ao menos a esses objetos públicos : as views internas que um usuário comum NUNCA deveria ter acesso são as DBA_xxx, essas sim mostram TUDO DE TODOS os usuários, é informação restrita…
Exemplo :
=> crio um usuário com mínimo privilégio, só conectar no banco :
SYSTEM:@XE:SQL>create user zezinho identified by pobre;
Usuário criado.
SYSTEM:@XE:SQL>grant create session to zezinho;
Concessão bem-sucedida.
SYSTEM:@XE:SQL>exit
Desconectado de Oracle Database 11g Express Edition Release 11.2.0.2.0 – 64bit Production==> agora conecto com esse usuário :
C:Usersjlchi_000>sqlplus zezinho/pobre
SQL*Plus: Release 11.2.0.2.0 Production
Conectado a:
Oracle Database 11g Express Edition Release 11.2.0.2.0 – 64bit ProductionZEZINHO:@XE:SQL>
==> veja que como não tenho nenhum objeto meu mesmo, a USER_OBJECTS vai parecer vazia :
ZEZINHO:@XE:SQL>select * from user_objects;
não há linhas selecionadas
ZEZINHO:@XE:SQL>
===> NÂO HÁ PORÉM como vc impedir o usuário de consultar/ler a USER_OBJECTS :
ZEZINHO:@XE:SQL>desc user_objects
Nome Nulo? Tipo
———————————————————————- ——– ————————————————
OBJECT_NAME VARCHAR2(128)
SUBOBJECT_NAME VARCHAR2(30)
OBJECT_ID NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(19)
CREATED DATE
LAST_DDL_TIME DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)
NAMESPACE NUMBER
EDITION_NAME VARCHAR2(30)==> como eu disse, esses objetos internos fazem parte da ARQUITETURA DE FUNCIONAMENTO DO RDBMS ORACLE, todos e qualquer um TEM que ter acesso a eles, o que vai acontecer é que se para os objetos de banco de dados para os quais o usuário não tem dados registrados eles vão parecer vazios, como o USER_OBJECTS acima…
No caso do ALL_OBJECTS, mesmo ninguém dando GRANT de select nem de INSERT nem de UPDATE em nada , POR DEFAULT e PADRÃO como eu disse qualquer um tem que ter acesso a alguns objetos do banco :ZEZINHO:@XE:SQL>select distinct owner, object_type, status from all_objects;
OWNER OBJECT_TYPE STATUS
—————- ——————- ——-
SYS FUNCTION VALID
SYS CONSUMER GROUP VALID
SYS WINDOW VALID
SYS PROGRAM VALID
CTXSYS TABLE VALID
XDB VIEW VALID
MDSYS TABLE VALID
MDSYS OPERATOR VALID
APEX_040000 TABLE VALID
APEX_040000 TYPE VALID
SYS PROCEDURE VALID
SYS EVALUATION CONTEXT VALID
APEX_040000 PACKAGE VALID
APEX_040000 FUNCTION VALID
SYS EDITION VALID
PUBLIC SYNONYM VALID
SYS PACKAGE VALID
SYSTEM TABLE VALID
SYSTEM VIEW VALID
XDB SEQUENCE VALID
XDB INDEXTYPE VALID
MDSYS FUNCTION VALID
APEX_040000 PROCEDURE VALID
SYS TABLE VALID
SYS OPERATOR VALID
XDB XML SCHEMA VALID
MDSYS PACKAGE VALID
MDSYS SEQUENCE VALID
APEX_040000 VIEW VALID
SYS DESTINATION VALID
CTXSYS TYPE VALID
CTXSYS PACKAGE VALID
CTXSYS INDEXTYPE VALID
SYS SCHEDULER GROUP VALID
MDSYS TYPE VALID
MDSYS INDEXTYPE VALID
SYS VIEW VALID
SYS JOB CLASS VALID
SYS SCHEDULE VALID
XDB TYPE VALID
XDB TABLE VALID
XDB PACKAGE VALID
APEX_040000 SEQUENCE VALID
SYS SEQUENCE VALID
SYS TYPE VALID
CTXSYS VIEW VALID
CTXSYS OPERATOR VALID
XDB FUNCTION VALID
XDB OPERATOR VALID
MDSYS VIEW VALID50 linhas selecionadas.
ZEZINHO:@XE:SQL>
==> *** TODOS *** esses usuários aí de cima são usuários internos do RDBMS ou de add-ons/features do RDBMS, então TODO MUNDO que for usar esse database TEM QUE TER mínimos privs neles, POR ISSO mesmo este usuário zemané não vem com a ALL_OBJECTS ‘zerada’…. Se ela viesse ‘zerada’ , COMO que o usuário ia ‘saber’ o que foi dado acesso pra ele ???
Já se esse usuário baixo nível tentar acessar as views DBA_xxx aí sim OBVIAMENTE não vão conseguir :
ZEZINHO:@XE:SQL>desc dba_objects
ERROR:
ORA-04043: o objeto “SYS”.”DBA_OBJECTS” não existeZEZINHO:@XE:SQL>select * from DBA_OBJECTS;
select * from DBA_OBJECTS
*
ERRO na linha 1:
ORA-00942: a tabela ou view não existeZEZINHO:@XE:SQL>
==> Pois neste caso SIM, se ele tivesse acesso ele poderia ficar sabendo de estruturas/informações de OUTROS schemas do database, aí não….
[]s
Chiappa
11 de janeiro de 2018 at 9:05 pm #109126acg1574ParticipantChiappa muito bom, lhe agradeço pela bela resposta, fiz o teste aqui e realmente ´eisso mesmo, obrigado, valew
11 de janeiro de 2018 at 9:07 pm #109127acg1574Participantengraçado, que eu nao dei privilegio a esse usuario de create session, so dei permissao a ele de connect, e ele conectou normal no banco de dados, faço leituras nas tabelas normal, nao precisei do create session, to usando a versao 11 do oracle
nao precisa mais dessa permissao ?11 de janeiro de 2018 at 10:05 pm #109128José Laurindo ChiappaModeratorNa verdade o conceito é : vc tanto pode dar GRANTs diretamente dos privilégios QUANTo poder dar GRANTs de uma ROLE, a ROLE seria um ‘pacote’ de privilégios…. CONNECT é uma ROLE (** não ** é uma permissão, não é um privilégio, é uma ROLE) , role essa que o RDBMS já traz pronta…
Se por curiosidade vc quiser ver os privs de sistema que a role CONNECT contém, vc pode consultar assim :SYSTEM:@XE:SQL>select grantee, privilege, admin_option from dba_sys_privs where grantee=’CONNECT’;
GRANTEE PRIVILEGE ADM
—————————— —————————————- —
CONNECT CREATE SESSION NOSYSTEM:@XE:SQL>
==> veja que essa role CONNECT não possui privs em tabelas e nem recebeu outras roles :
SYSTEM:@XE:SQL>select grantee, privilege from dba_tab_privs where grantee=’CONNECT’;
não há linhas selecionadas
SYSTEM:@XE:SQL>select grantee, granted_role from dba_role_privs where grantee=’CONNECT’;
não há linhas selecionadas
SYSTEM:@XE:SQL>
==> Isso está Documentando nos manuais Oracle, https://docs.oracle.com/cd/B19306_01/network.102/b14266/appendixa.htm por exemplo no caso do banco 10gR2…. Assim, neste teu caso ao dar o GRANT da role CONNECT (role essa que contém apenas o privilégio CREATE SESSION) pro usuário que criou, vc na prática fez o mesmo que eu ao dar diretamente o privilégio de sistema CREATE SESSION pro meu usuário…
[]s
Chiappa
OBS : CONNECT não é a única ROLE que pode ser atribuída a alguém e que o RDBMS Oracle já traz criada/montada por default :
SYSTEM:@XE:SQL>select role from dba_roles;
ROLE
——————————
CONNECT
RESOURCE
DBA
SELECT_CATALOG_ROLE
EXECUTE_CATALOG_ROLE
DELETE_CATALOG_ROLE
EXP_FULL_DATABASE
IMP_FULL_DATABASE
LOGSTDBY_ADMINISTRATOR
DBFS_ROLE
AQ_ADMINISTRATOR_ROLE
AQ_USER_ROLE
DATAPUMP_EXP_FULL_DATABASE
DATAPUMP_IMP_FULL_DATABASE
ADM_PARALLEL_EXECUTE_TASK
GATHER_SYSTEM_STATISTICS
XDB_WEBSERVICES_OVER_HTTP
RECOVERY_CATALOG_OWNER
SCHEDULER_ADMIN
OEM_ADVISOR
OEM_MONITOR
PLUSTRACE
CTXAPP
XDBADMIN
XDB_SET_INVOKER
AUTHENTICATEDUSER
XDB_WEBSERVICES
XDB_WEBSERVICES_WITH_PUBLIC
APEX_ADMINISTRATOR_ROLE33 linhas selecionadas.
SYSTEM:@XE:SQL>
==> todas essas ROLEs acima ou já são criadas automaticamente pelo RDBMS ou são criadas por add-ons/features do RDBMS que foram ativadas, e cada uma delas possui um conjunto de privilégios dentro dela…
11 de janeiro de 2018 at 10:17 pm #109129acg1574Participantbacana Chiappa , valew mais uma vez, muito bom, obrigado pelas respostas, valew, ate a proxima.
11 de janeiro de 2018 at 10:43 pm #109130acg1574Participantpessoal como faço para trancar o topico que foi resolvido ?
-
AuthorPosts
- You must be logged in to reply to this topic.