SQL Server - Esecuzione Delete tramite Stored con login differenti

mercoledì 25 marzo 2009 - 13.07

veryandr Profilo | Newbie


Buongiorno, avrei una questione da porre premettendo che non sono un grande esperto di amministrazione DB.Ho un applicazione web (C#) che utilizza numerose Stored per effettuare accesso ai dati.Ho adesso la necessità che una tipologia di utenti dell'applicativo possa accedere ad essi in modalità di sola lettura sul DB.Per questo ho creato sulla base dati un'utenza readonly a cui ho attrubuito il ruolo di db_readonly, e utilizzo questa utenza di DB solo nei casi in cui mi serve (modificando la string connection in C#).

Ho però un problema, cioè che quando da codice C# eseguo una stored al cui interno c'è ad esempio una Delete, tale delete viene tranquillamente eseguita anche se l'utente con cui mi collego al DB è readonly . Ho letto che il problema sta nel fatto che tale stored viene eseguita utilizzando l'utente con cui è stata creata (nel mio caso dbo)e quindi dato che dbo è l'owner del DB non ha problemi a fare la delete.

Vi chiedo se l'unica soluzione che ho è quella di creare tutte le stored sotto l'utenza readonly in modo che, quando sono collegato al DB con tale username, vengano eseguite con quell'utenza che non ha diritti di scrittura, oppure se esiste una via d'uscita alternativa.

Spero possiate darmi una mano!

Grazie,

Andrea V.

lbenaglia Profilo | Guru

>Ho un applicazione
>web (C#) che utilizza numerose Stored per effettuare accesso
>ai dati.Ho adesso la necessità che una tipologia di utenti dell'applicativo
>possa accedere ad essi in modalità di sola lettura sul DB.Per
>questo ho creato sulla base dati un'utenza readonly a cui ho
>attrubuito il ruolo di db_readonly, e utilizzo questa utenza
>di DB solo nei casi in cui mi serve (modificando la string connection
>in C#).

Ciao Andrea,

Non era per caso la database role db_datareader?
db_readonly non mi dice niente e comunque anche se fosse db_datareader le permission ereditate consentono l'accesso in lettura alle tabelle utente ma non i diritti di esecuzione delle stored procedures che necessitano di una GRANT EXECUTE aggiuntiva.

>Ho però un problema, cioè che quando da codice C# eseguo una
>stored al cui interno c'è ad esempio una Delete, tale delete
>viene tranquillamente eseguita anche se l'utente con cui mi collego
>al DB è readonly .
Mmmmm... prova a leggere questo articolo di Luca che spiega nel dettaglio i concetti di Autenticazione ed Autorizzazione:
http://technet.microsoft.com/it-it/library/cc645510.aspx

>Ho letto che il problema sta nel fatto
>che tale stored viene eseguita utilizzando l'utente con cui è
>stata creata (nel mio caso dbo)e quindi dato che dbo è l'owner
>del DB non ha problemi a fare la delete.
dbo è lo schema a cui la procedura appartiene (consideralo un Namespace).
Tu devi creare una nuova login a livello di istanza, uno user account a livello di database mappato sulla precedente login ed assegnare le GRANT EXECUTE sulle stored procedure e le GRANT SELECT sulle tabelle che ti interessano.

>Grazie,
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

veryandr Profilo | Newbie


>Ciao Andrea,
>
>Non era per caso la database role db_datareader?
>db_readonly non mi dice niente e comunque anche se fosse db_datareader
>le permission ereditate consentono l'accesso in lettura alle
>tabelle utente ma non i diritti di esecuzione delle stored procedures
>che necessitano di una GRANT EXECUTE aggiuntiva.

Si hai ragione il ruolo era db_datareader. Inoltre mi ero scordato di dire che avevo già provveduto ad attribuire al mio utente readonly le grant per fare le execute di tutte le stored sul DB di mio interesse (usando Grant Execute on [nome stored] to [readonly]).Infatti dal codice c# riesco a fare eseguire le stored all'utente readonly, solo che tutto ciò che sta nella stored viene eseguito senza tenere conto che l'utente readonly (che se non ho capito male è l'utente con cui SQL Server dovrebbe lanciare la stored dato che io sono collegato con quella login) potrebbe solo "leggere" su tale DB.

>Tu devi creare una nuova login a livello di istanza, uno user
>account a livello di database mappato sulla precedente login
>ed assegnare le GRANT EXECUTE sulle stored procedure
>>e le GRANT SELECT sulle tabelle che ti interessano.

Le login a livello di server e database le ho già impostate, così come le GRANT EXECUTE su tutte le stored.
Tu pensi che tutto ciò possa essere risolto dando soltanto le GRANT SELECT su tutte le tabelle del DB per il mio utente readonly ??

Grazie per il supporto!


Andrea V.

>--
>Lorenzo Benaglia
>Microsoft MVP - SQL Server
>http://blogs.dotnethell.it/lorenzo/
>http://italy.mvps.org

lbenaglia Profilo | Guru

>... solo che tutto ciò che sta nella stored
>viene eseguito senza tenere conto che l'utente readonly
Questo è poco ma sicuro
La GRANT di EXECUTE ti assegna i permessi di esecuzione a prescindere dalle operazioni svolte dalla stored procedure!

>Tu pensi che tutto ciò possa essere risolto dando soltanto le
>GRANT SELECT su tutte le tabelle del DB per il mio utente readonly
No, dato che il tuo user ha già il ruolo db_datareader, quindi le GRANT di SELECT sarebbero del tutto inutili.

>Grazie per il supporto!
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

veryandr Profilo | Newbie

>Questo è poco ma sicuro
>La GRANT di EXECUTE ti assegna i permessi di esecuzione a prescindere
>dalle operazioni svolte dalla stored procedure!

A questo punto ti pongo l'ultima domanda. Ma quindi è possibile rendere possibile l'esecuzione delle stored al mio utente readonly (concedendogli come ho già fatto le GRANT di EXECUTE) senza che però tramite queste stored lui possa fare operazioni di scrittura sul DB ? Se si come ?

Se invece non è possibile significa che le grant di execute sulle stored vincono sul ruolo dell'utente (che potrebbe solo leggere), corretto? Mi sembra una cosa un po'strana non credi?


Andrea V.


>Lorenzo Benaglia
>Microsoft MVP - SQL Server
>http://blogs.dotnethell.it/lorenzo/
>http://italy.mvps.org

lbenaglia Profilo | Guru

>>Questo è poco ma sicuro
>>La GRANT di EXECUTE ti assegna i permessi di esecuzione a prescindere
>>dalle operazioni svolte dalla stored procedure!
>
>A questo punto ti pongo l'ultima domanda. Ma quindi è possibile
>rendere possibile l'esecuzione delle stored al mio utente readonly
>(concedendogli come ho già fatto le GRANT di EXECUTE) senza che
>però tramite queste stored lui possa fare operazioni di scrittura
>sul DB ? Se si come ?
No.
Una stored procedure devi intenderla come una "black box" ed un utente può eseguirla o meno.
Ipoteticamente potresti rompere la catena di ownership in modo che quando l'utente readonly la esegue, SQL Server dietro le quinte verifica che abbia le permission sugli oggetti richiamati dalla Stored Procedure, ma nel caso in cui avviene una scrittura l'esecuzione darà origine ad una eccezione (eventualmente trappabile mediante blocchi TRY...CATCH).

>Se invece non è possibile significa che le grant di execute sulle
>stored vincono sul ruolo dell'utente (che potrebbe solo leggere),
>corretto?
Diciamo che le GRANT di EXECUTE sono allo stesso livello delle altre GRANT.
Il ruolo db_datareader agisce esclusivamente sulle tabelle utente ma non ha alcuna influenza sulle stored procedure.

> Mi sembra una cosa un po'strana non credi?
No, per niente
Una stored procedure può contenere decine e decine di comandi dei più disparati, quindi se un utente ha i diritti di esecuzione li esegue in blocco.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5