Concessione per gli utenti su diversi schemi

Question

Ho tabelle nello schema A. ho creato in vista dello schema B utilizzando le tabelle nello schema A.

voglio concedere le autorizzazioni a un utente di selezionare i dati dalla vista nello schema B.

Per funzionare, so che dobbiamo abilitare l'opzione di concessione sulle tabelle nello schema A all'utente B. Ma io voglio farlo in un singolo script (questo script deve essere nello schema B). C'è un modo per farlo utilizzando il nome utente/password dello schema A.

Answer 1

Solo collegandosi come utente A in un dato momento. È ancora possibile farlo in uno script se si vuole veramente:

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

Naturalmente ora si dispone di uno script in giro che espone due set di credenziali utente a chiunque possa leggerlo. Quindi, qualcosa su cui riflettere prima di fare qualcosa, ad esempio.

Se si desidera che altri utenti possano selezionare dalla vista, non è necessario concedere autorizzazioni esplicite a userA.my_table; finché il proprietario della vista può vedere la tabella sottostante, gli altri utenti devono solo essere in grado di vedere la vista. Il che spesso è un po 'il punto (o uno di essi) in quanto è possibile limitare la visualizzazione per esporre solo i dati selezionati dalla tabella sottostante al resto del mondo. I suppone che si abbia una ragione per non creare la vista nello schema A.

non sono sicuro se siete veramente chiedendo la concessione di selezionare per l'utente B admin option con modo che l'utente B può quindi concedere selezionare l'utente A di tavolo ad altre persone. Se è possibile, non sembra una buona idea e non è necessario che la vista funzioni.

Answer 2

Non è insolito desiderare un singolo script per distribuire una modifica. Il fatto è che uno script di questo tipo deve essere eseguito da un utente esperto, perché deve avere i privilegi di sistema a QUALSIASI livello. Questo di solito significa un account DBA, preferibilmente un account di applicazione ma altrimenti SYSTEM o SYS.

Quindi lo script che si desidera sarebbe simile a questa:

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 
/

Uno scenario comune è che abbiamo una serie di singoli script che sono state scritte per essere eseguito da diversi utenti, ma che ora abbiamo bisogno di impacchettare fino a una singola implementazione. Gli script originali non contengono i nomi degli schemi e ci sono molte buone ragioni per cui non vorremmo hardcode negli script.

Un modo per costruire lo script maestro è quello di utilizzare modificare la sintassi 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 

Abbiamo ancora bisogno di un utente DBA per eseguire lo script master. Un vantaggio del passaggio allo schema corrente è che ci consente di distribuire oggetti come i collegamenti ai database, che attraverso una stranezza della sintassi non possono avere il nome dello schema nella loro dichiarazione. Un trucco è che l'utente non cambia, quindi uno script che impiega la pseudo colonna USER può produrre risultati indesiderati.

Answer 3

Consenti all'utente di selezionare una concessione sulle sue tabelle su B e includere l'opzione di sovvenzione.

Come utente A:

GRANT select ON table TO user_b WITH GRANT OPTION; 

Sia l'utente B borsa di selezionare il suo punto di vista per l'utente A e includono l'opzione 'grant'.

Come utente B:

GRANT select ON view TO user_a WITH GRANT OPTION; 

Come utente A:

GRANT select on user_b.view TO user_c; 

Questo permette all'utente A passare questo grant ad altri utenti.

Answer 4

semplicemente eseguire la query

GRANT INSERT, SELECT, UPDATE, DELETE ON TABLE1 PER Schema2;