Pular para o conteúdo
  • Este tópico contém 6 respostas, 2 vozes e foi atualizado pela última vez 6 anos, 8 meses atrás por Avatar de acg1574acg1574.
Visualizando 7 posts - 1 até 7 (de 7 do total)
  • Autor
    Posts
  • #109122
    Avatar de acg1574acg1574
    Participante

      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 ?

      #109124
      Avatar photoJosé Laurindo Chiappa
      Moderador

        Entã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 Production

        ZEZINHO:@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 VALID

        50 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 existe

        ZEZINHO:@XE:SQL>select * from DBA_OBJECTS;
        select * from DBA_OBJECTS
        *
        ERRO na linha 1:
        ORA-00942: a tabela ou view não existe

        ZEZINHO:@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

        #109126
        Avatar de acg1574acg1574
        Participante

          Chiappa muito bom, lhe agradeço pela bela resposta, fiz o teste aqui e realmente ´eisso mesmo, obrigado, valew

          #109127
          Avatar de acg1574acg1574
          Participante

            engraç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 ?

            #109128
            Avatar photoJosé Laurindo Chiappa
            Moderador

              Na 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 NO

              SYSTEM:@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_ROLE

              33 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…

              #109129
              Avatar de acg1574acg1574
              Participante

                bacana Chiappa , valew mais uma vez, muito bom, obrigado pelas respostas, valew, ate a proxima.

                #109130
                Avatar de acg1574acg1574
                Participante

                  pessoal como faço para trancar o topico que foi resolvido ?

                Visualizando 7 posts - 1 até 7 (de 7 do total)
                • Você deve fazer login para responder a este tópico.
                plugins premium WordPress