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, "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]
>
