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]