Stored procedure e autorizzazioni: EXECUTE è sufficiente?

Question

Ho un database SQL Server 2008 in cui tutti gli accessi alle tabelle sottostanti vengono eseguiti tramite stored procedure. Alcune stored procedure semplicemente SELECT i record dalle tabelle mentre altri UPDATE, INSERT e DELETE.

Se una stored procedure AGGIORNA una tabella, l'utente che esegue la stored procedure ha anche bisogno delle autorizzazioni UPDATE per le tabelle interessate o il fatto che disponga delle autorizzazioni EXECUTE per la stored procedure sufficiente?

Fondamentalmente mi chiedo se fornire all'utente le autorizzazioni EXECUTE alle stored procedure sia sufficiente o è necessario fornire loro le autorizzazioni SELECT, UPDATE, DELETE e INSERT alle tabelle affinché le stored procedure funzionino. Grazie.

[EDIT] Nella maggior parte delle mie stored procedure sembra effettivamente che EXECUTE sia sufficiente. Tuttavia, ho trovato che nelle stored procedure in cui è stato utilizzato "Execute sp_Executesql" EXECUTE non era sufficiente. Le tabelle coinvolte necessitavano di autorizzazioni per le azioni eseguite all'interno di "sp_Executesql".

Answer 1

Le autorizzazioni di esecuzione per la stored procedure sono sufficienti.

CREATE TABLE dbo.Temp(n int) 

GO 
DENY INSERT ON dbo.Temp TO <your role> 
GO 
CREATE PROCEDURE dbo.SPTemp(@Int int) 
AS 

INSERT dbo.Temp 
SELECT @Int 

GO 

GRANT EXEC ON dbo.SPTemp TO <your role> 

GO 

Poi il (non db_owner) utente avrà i seguenti diritti:

EXEC dbo.SPTemp 10 
GO 

INSERT dbo.Temp --INSERT permission was denied on the object 'Temp' 
SELECT 10 

Tuttavia, se si c'è SQL dinamico all'interno dbo.SPTemp che tenta di inserire in dbo.Temp allora che avrà esito negativo. In questo caso, sarà necessario concedere l'autorizzazione diretta sul tavolo.

Answer 2

Le autorizzazioni sulle tabelle non vengono controllate (incluso DENY) se le tabelle e proc hanno lo stesso proprietario. Possono essere anche in schemi diversi fintanto che gli schemi hanno lo stesso proprietario.

Vedi Ownership chaining su MSDN

Modifica, da un commento da una risposta cancellato.

Il contesto è sempre il login corrente a meno che non sia stato utilizzato EXECUTE AS: solo le autorizzazioni DML dell'oggetto di riferimento non vengono controllate. Prova OBJECT_ID (referencedtable) in un processo memorizzato in cui non vengono assegnati diritti a referencedtable. Dà NULL. Se eseguito dal proprietario del processo memorizzato, restituirebbe un valore in quanto Owener dispone di diritti su referenced

Answer 3

L'autorizzazione di esecuzione su una stored procedure che consente di inserire, aggiornare o eliminare è sufficiente. Non è necessario concedere tali autorizzazioni a livello di tabella. In realtà, vorrei scoraggiare questo approccio. L'utilizzo di una procedura memorizzata offre un maggiore controllo su come avviene la modifica. Ad esempio, potresti voler fare qualche controllo prima di consentire l'aggiornamento. L'utilizzo di una procedura memorizzata può anche aiutare a prevenire incidenti gravi, ad esempio l'eliminazione di tutte le righe nella tabella perché qualcuno ha dimenticato la clausola WHERE!

Answer 4

GRAZIE GRAZIE! Ho avuto un problema simile. Questo mi ha portato alla risposta.

Stavo tentando di troncare una tabella in una stored procedure che richiamava altre stored procedure che erano nidificate nelle istruzioni IF.

Il mio errore è stato

Il server principale "dominio \ my_id" non è in grado di accedere al database "2nd_DB" nel contesto di protezione corrente.

avevo dato la chiamata memorizzati diritti procedure per fare il Tronca (EXECUTE come auto), che poi ha causato un problema perché sé non aveva diritti sul 2 ° DB. La nostra soluzione era spostare il troncato su un altro SP, includendo l'ESEGUI COME AUTOS. Ora chiamiamo il truncate SP, eseguiamo l'elaborazione dei dati, stabiliamo la logica e chiamiamo il 3 ° SP appropriato.

Answer 5

Forse è possibile utilizzare

"con l'esecuzione come proprietario"

quando si crea la stored procedure.such come di seguito:

create procedure XXX 
with execute as owner 
as 
begin 
... 
end 
go 

allora avete solo bisogno di concedere all'utente il permesso di esecuzione per la stored procedure XXX.