Ok Chiappa!
Realmente o privilégio para criar a view está na role CONNECT.
Obrigado pelos esclarecimentos e pelo script também.
Ronaldo
Em 24/07/07, jlchiappa <[EMAIL PROTECTED]> escreveu:
>
> Colega, seguinte : é falso que um usuário que não tenha priv de CREATE
> VIEW possa criar uma view, exemplo :
>
> [EMAIL PROTECTED]:SQL>create user zemane identified by zemane;
>
> Usuário criado.
>
> [EMAIL PROTECTED]:SQL>grant create session to zemane;
>
> Concessão bem-sucedida.
>
> [EMAIL PROTECTED]:SQL>grant select on scott.dept to zemane;
>
> Concessão bem-sucedida.
> ==> veja que ** REALMENTE ** o usuário não tem o privs de CREATE VIEW :
>
> [EMAIL PROTECTED]:SQL>@privs_by_user
>
> Enter Username : zemane
>
> Roles granted to user
>
> não há linhas selecionadas
>
> Table Privileges granted to a user through roles
>
> não há linhas selecionadas
>
> System Privileges assigned to a user through roles
>
> não há linhas selecionadas
>
> Table privileges assigned directly to a user
>
> OWNER TABLE_NAME PRIVILEGE
> --------------- ---------------------------------
> ---------------------------------
> SCOTT DEPT SELECT
>
> System privileges assigned directly to a user
>
> PRIVILEGE ADM
> --------------------------------- ---
> CREATE SESSION NO
>
> ==> conectando como esse usuário, testo :
>
> [EMAIL PROTECTED]:SQL>select * from scott.dept where rownum < 3;
>
> DEPTNO DNAME LOC R
> ------------------ ------------------ ------------- -
> 10 ACCOUNTING NEW YORK
> 20 RESEARCH DALLAS
>
> [EMAIL PROTECTED]:SQL>create view V_TESTE as select * from scott.dept where
> rownum < 3;
> create view V_TESTE as select * from scott.dept where rownum < 3
> *
> ERRO na linha 1:
> ORA-01031: privilégios insuficientes
>
> yes ??? Segue o script script usado :
>
> [EMAIL PROTECTED]:SQL>get privs_by_user.sql
> 1 -- script de check de privs
> 2 set echo off
> 3 set verify off
> 4 set pages 200
> 5 col granted_role form a20
> 6 col owner form a15
> 7 col table_name form a33
> 8 col privilege form a33
> 9 ACCEPT username prompt 'Enter Username : '
> 10 PROMPT Roles granted to user
> 11 SELECT granted_role,admin_option,default_role
> 12 FROM dba_role_privs
> 13 WHERE grantee=UPPER('&username')
> 14 ORDER BY 1;
> 15 PROMPT Table Privileges granted to a user through roles
> 16 SELECT granted_role, owner, table_name, privilege
> 17 FROM ( SELECT granted_role
> 18 FROM dba_role_privs WHERE grantee=UPPER('&username')
> 19 UNION
> 20 SELECT granted_role
> 21 FROM role_role_privs
> 22 WHERE role in (SELECT granted_role
> 23 FROM dba_role_privs WHERE grantee=UPPER('&username')
> 24 )
> 25 ) roles, dba_tab_privs
> 26 WHERE granted_role=grantee
> 27 ORder by 1,2,3,4;
> 28 PROMPT System Privileges assigned to a user through roles
> 29 SELECT granted_role, privilege
> 30 FROM ( SELECT granted_role
> 31 FROM dba_role_privs WHERE grantee=UPPER('&username')
> 32 UNION
> 33 SELECT granted_role
> 34 FROM role_role_privs
> 35 WHERE role in (SELECT granted_role
> 36 FROM dba_role_privs WHERE grantee=UPPER('&username')
> 37 )
> 38 ) roles, dba_sys_privs
> 39 WHERE granted_role=grantee
> 40 ORDER BY 1,2;
> 41 PROMPT Table privileges assigned directly to a user
> 42 SELECT owner, table_name, privilege
> 43 FROM dba_tab_privs
> 44 WHERE grantee=UPPER('&username')
> 45 ORDER BY 1,2,3;
> 46 PROMPT System privileges assigned directly to a user
> 47 SELECT privilege, admin_option
> 48 FROM dba_sys_privs
> 49 WHERE grantee=UPPER('&username');
>
> ==> rode o script e veja lá se na verdade o usuário não recebeu o
> privilégio VIA ROLE !!!! Evidentemente, se tal aconteceu, o REVOKE vai
> CORRETAMENTE te responder que o priv direto não existe, o que existe é
> a role... Exemplo :
>
> [EMAIL PROTECTED]:SQL>grant connect, resource to zemane;
>
> Concessão bem-sucedida.
>
> [EMAIL PROTECTED]:SQL>@privs_by_user
> Gravou file D:\dba_scripts\sqlplus_settings.sql
> Enter Username : zemane
> Roles granted to user
>
> GRANTED_ROLE ADM DEF
> -------------------- --- ---
> CONNECT NO YES
> RESOURCE NO YES
>
> Table Privileges granted to a user through roles
>
> não há linhas selecionadas
>
> System Privileges assigned to a user through roles
>
> GRANTED_ROLE PRIVILEGE
> -------------------- ---------------------------------
> CONNECT ALTER SESSION
> CONNECT CREATE CLUSTER
> CONNECT CREATE DATABASE LINK
> CONNECT CREATE SEQUENCE
> CONNECT CREATE SESSION
> CONNECT CREATE SYNONYM
> CONNECT CREATE TABLE
> CONNECT CREATE VIEW
> RESOURCE CREATE CLUSTER
> RESOURCE CREATE INDEXTYPE
> RESOURCE CREATE OPERATOR
> RESOURCE CREATE PROCEDURE
> RESOURCE CREATE SEQUENCE
> RESOURCE CREATE TABLE
> RESOURCE CREATE TRIGGER
> RESOURCE CREATE TYPE
>
> 16 linhas selecionadas.
>
> Table privileges assigned directly to a user
>
> OWNER TABLE_NAME PRIVILEGE
> --------------- ---------------------------------
> ---------------------------------
> SCOTT DEPT SELECT
>
> System privileges assigned directly to a user
>
> PRIVILEGE ADM
> --------------------------------- ---
> CREATE SESSION NO
> UNLIMITED TABLESPACE NO
>
> ==> viu a role CONNECT *** implicitamente ** deu CREATE VIEW pro
> cara... Se eu tentar REVOKAR, como eu disse NÂO funciona pois o
> usuário NÂO RECEBEU esse priv diretamente :
>
> [EMAIL PROTECTED]:SQL>revoke create view from zemane;
>
> revoke create view from zemane
> *
> ERRO na linha 1:
> ORA-01952: os privilégios de sistema não concederam para 'ZEMANE'
>
> Sim ???? Caso não seja esse o caso, outra possibilidade é que o CREATE
> VIEW simplesmente foi dado para PUBLIC, aí qquer um o tem, INCLUSIVE
> esse usuário...
>
> Quanto às sua outra dúvida : a view (pensando sempre em views
> "simples", view materializada é OUTRA coisa), NADA MAIS É do que uma
> query, do que um TEXTO CONTENDO UM SELECT, texto esse armazenado no
> banco de dados na tablespace SYSTEM, junto com outros textos
> similares, tais como as Procedures, Triggers, ok ? Quando vc faz um
> SELECT nn FROM nomedaview, o que ocorre é que o TEXTO DO SELECT da
> view é lido e RE-executado , a view *** NÂO POSSUI *** registros, ela
> é uma consulta em cima de tabelas reais, e a cada vez que vc aciona a
> view, a consulta é refeita e os dados são puxados da tabela real, NADA
> MAIS QUE isso, portanto NÂO HÁ o que dados que guardar em tablespace
> alguma, certo ?? Há muitos livros-texto que dizem que a view é como se
> fosse uma "sub-tabela", que "armazena" registros que vêm da tabela
> real citada no select - TODOS esses livros-textos estão simplesmente
> ERRADOS, tá ? Vc pode comprovar isso não só lendo a documentação
> oficial Oracle, como também consultando as views do sistema que
> mostram consumo nas tablespaces (ie, DBA_EXTENTS e DBA_SEGMENTS), veja
> lá que vc NUNCA vai achar lá área NENHUMA ocupada por "dados de uma
> view", isso não existe, ponto.
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>,
> "Ronaldo Pinto"
> <[EMAIL PROTECTED]> escreveu
> >
> > Olá a todos!
> > Fazendo alguns testes no banco de estudos 9i percebí que quando um
> usuario
> > recebe permissão de select em uma tabela, ele consegue criar views
> naquela
> > tabela mesmo não tendo o privilégio "create view".
> > As dúvidas são:
> > Se o usuário não tem cota em nenhuma tablespace, onde as informações
> dessa
> > view são guardadas?
> > O fato do usuário não ter o privilégio de "create view" não deveria
> > impedí-lo de criar views?
> > Como posso remover esse privilégio? Tentei "revoke" e recebo a
> informação de
> > que o privilégio não foi aplicado.
> >
> > Obrigado pelos esclarecimentos,
> >
> > Ronaldo
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
[As partes desta mensagem que não continham texto foram removidas]
