stored procedure che chiama i dati in uno schema diverso

Question

SQL Server 2008 R2: normalmente, viene creata la nostra tabella e la stored procedure e si concede a un utente di eseguire i diritti sulla stored procedure. Non è mai necessario concedere diritti specifici alle tabelle o alle visualizzazioni poiché se l'utente può eseguire la stored procedure, SQL Server deduce che la stored procedure deve poter eseguire le istruzioni select/insert/update. Funziona bene perché abbiamo a che fare solo con uno schema, ma ora abbiamo uno scenario in cui le tabelle sono in uno schema, ma una stored procedure è in un'altra. Quando l'utente esegue la stored procedure, ottengono un errore:

Msg 229, Level 14, State 5, Procedure teststoredprocedure, Line 7 The SELECT permission was denied on the object 'testtable', database 'testdatabase', schema 'testschema'.

teststoredprocedure è in uno schema diverso da quello testtable. È possibile consentire alla stored procedure di selezionare dalle tabelle, senza concedere all'utente diritti specifici per tali tabelle?

Answer 1

è necessario dare il proprietario della stored procedure WITH GRANT accesso alla tabella .

Generalmente uno schema è di proprietà di un ruolo con lo stesso nome dello schema, in modo da permettere storedprocschema.teststoredprocedure per accedere alla tabella sarebbe:

GRANT SELECT on testschema.testtable TO storedprocschema WITH GRANT 

Questo dovrebbe funzionare se e solo se la tabella è in lo stesso database del proc.

Per ottenere lo stesso risultato con una tabella in un database diverso è possibile:

• Attiva "Croce concatenamento database delle proprietà"

• Spostare la procedura per l'altro database, e hanno un procedura di shim nel database originale che la chiama. Quindi gestire le autorizzazioni su entrambe le procedure.

Answer 2

Sì, è possibile. Ecco cosa si vuole fare:

alter procedure teststoredprocedure 
with execute as 'UserWithPermissions' 
-- rest of stored proc code 

Dove UserWithPermissions ha le autorizzazioni necessarie per i vostri oggetti di database che si sta tentando di eseguire nuovamente operazioni CRUD.

Al contrario, se il contesto di protezione utente del database dispone delle autorizzazioni necessarie, è possibile utilizzare la scorciatoia per raggiungere questo obiettivo così:

with execute as self