2010-11-18 19 views
7

tengo tablas en el esquema A. creé vistas en esquema B utilizando las tablas en el esquema A.Concesión de permiso a los usuarios en diferentes esquemas de

que desea conceder permisos a un usuario para seleccionar los datos de la vista en el esquema B.

Para que esto funcione, sé que tenemos que habilitar la opción de concesión en las tablas del esquema A para el usuario B. Pero quiero hacerlo en un único script (este script debe estar en el esquema B). ¿Hay alguna manera de hacer esto utilizando el nombre de usuario/contraseña del esquema A.

+2

No tiene sentido: las secuencias de comandos no existen en un esquema, son solo una lista de comandos que el usuario que está conectando a la instancia tiene el privilegio de ejecutar. Las declaraciones de concesión IIRC son por objeto (IE: tabla). Por favor, reformule su pregunta para que quede más claro de lo que está preguntando. –

Respuesta

2

Solo al conectarse como usuario A en algún punto. Todavía se puede hacer en una secuencia de comandos si realmente quiere:

connect userA/passwordA 
grant select on my_table to userB; 
connect userB/passwordB 
create view my_view as select * from userA.my_table; 

Por supuesto, ahora que tienen un guión por ahí que expone dos conjuntos de credenciales de usuario a cualquiera que pueda leerlo. Entonces, algo sobre lo que pensar antes de hacer en producción, por ejemplo.

Si desea que otros usuarios puedan seleccionar de la vista, no necesita otorgar permisos explícitos en userA.my_table; siempre que el propietario de la vista pueda ver la tabla subyacente, otros usuarios solo necesitan poder ver la vista. Que a menudo es un poco el punto (o uno de ellos) ya que puede restringir la vista para exponer solo los datos seleccionados de la tabla subyacente al resto del mundo. Supongo que tiene una razón para no crear la vista en el esquema A.

No estoy seguro si realmente está preguntando sobre la concesión de seleccionar al usuario B con la opción de administrador para que el usuario B pueda otorgar la selección del usuario A mesa a otras personas. Si eso es posible, no parece una buena idea, y no es necesario para que la vista funcione.

+0

'SYSTEM' también puede aplicar las concesiones, no necesariamente tiene que iniciar sesión como userA. De esta manera, no necesita las contraseñas en el script. –

+1

Cierto, supongo que estaba suponiendo que querer usar las credenciales de usuario A significaba que no tenían los privilegios de DBA. Lo leí porque son usuarios B pero también conocen a usuarioA. Qué inusual es que una suposición arbitraria sea problemática ... –

4

No es inusual querer tener un solo script para implementar un cambio. El hecho es que una secuencia de comandos debe ser ejecutada por un usuario avanzado, ya que necesita tener privilegios del sistema en el nivel ANY. Esto generalmente significa una cuenta de DBA, preferiblemente una cuenta de aplicación, pero de lo contrario SYSTEM o SYS.

Así que el script que desea se vería así:

grant select on user_a.t23 to user_b 
/
grant select on user_a.t42 to user_b 
/
create view user_b.v_69 as 
select t23.col1, t42.col2 
from user_a.t42 
     join user_a.t23 
      on (t42.id = t23.id) 
/
grant select on user_b.v_69 to user_c 
/

Un escenario común es que tenemos un conjunto de secuencias de comandos individuales que se han escrito para ser ejecutado por diferentes usuarios, pero que ahora tenemos que agrupar en una sola implementación. Las secuencias de comandos originales no contienen los nombres de los esquemas, y hay muchas buenas razones por las que no deseamos codificarlas en las secuencias de comandos.

Una forma de construir esa secuencia de comandos principal es utilizar la sintaxis cambiar CURRENT_SCHEMA:

alter session set current_schema=USER_A 
/
@run_grants_to_userb.sql 

alter session set current_schema=USER_B 
/
@create_view69.sql 
@run_grants_to_userc.sql 

Todavía necesitamos un usuario DBA para ejecutar el script principal. Una ventaja de cambiar el esquema actual es que nos permite implementar objetos como enlaces de bases de datos, que a través de una peculiaridad de sintaxis no pueden tener el nombre del esquema en su declaración. Una sorpresa es que el usuario no cambia, por lo que una secuencia de comandos que emplea la pseudocolumna del USUARIO puede producir resultados no deseados.

2

Deje que el usuario Una subvención seleccione en sus tablas a B e incluya la 'opción de concesión'.

Como usuario A:

GRANT select ON table TO user_b WITH GRANT OPTION; 

permitir al usuario seleccionar B subvención en sus puntos de vista a un usuario e incluir la opción 'subvención'.

Como usuario B:

GRANT select ON view TO user_a WITH GRANT OPTION; 

Como usuario A:

GRANT select on user_b.view TO user_c; 

Esto permite que el usuario A para pasar esta subvención a otros usuarios.

+0

B solo puede otorgar la selección en la vista a A si A ya le ha otorgado la opción WITH GRANT OPTION en su tabla. Además, no es necesario que A tenga una selección en la vista para que C pueda seleccionar en la vista. –

+0

Agregué la OPCIÓN WITH GRANT en la tabla de A a B. Creo que A necesita seleccionar en la vista para pasar esta concesión a C (como se indica en la pregunta, "¿Hay alguna manera de hacer esto usando el nombre de usuario/contraseña del esquema A. " –

+0

Hmmm, eso funcionará. La pregunta es contradictoria como señaló OMG Ponies, especificando un script en el Usuario B que usa el nombre de usuario/contraseña del Usuario B. –

1

sólo tiene que ejecutar la consulta

GRANT INSERT, SELECT, UPDATE, DELETE en Table1 A Schema2;

Cuestiones relacionadas