SQL Server - Esecuzione Delete tramite Stored con login differenti

mercoledì 25 marzo 2009 - 13.04

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.

alx_81 Profilo | Guru

>Buongiorno,
Ciao
>
>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.
Ma che grant dai alle stored procedure? E' buona norma definire l'accesso ad un ruolo a particolari stored procedure solamente. E gestire il tutto a ruoli..

>Grazie,
di nulla!
--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

veryandr Profilo | Newbie


>Ma che grant dai alle stored procedure? E' buona norma definire
>l'accesso ad un ruolo a particolari stored procedure solamente.
>E gestire il tutto a ruoli..

A tutte le stored avevo dato le GRANT di EXECUTE, immaginando che il ruolo di db_datareader assegnato all'utente fosse predominante rispetto alle grant sulle stored. Invece ho appurato che tali GRANT di Execute sulle stored concedono l'esecuzione di tutto ciò che sta dentro alle procedure indipendentemente da ciò che può fare l'utente. A questo punto, correggimi se sbaglio, sono costretto ad individuare tutte le stored che vanno a scrivere sul DB e negare ad esse le GRANT di EXECUTE, giusto ?

Grazie,

Andrea

>--
>
>Alessandro Alpi | SQL Server MVP
>
>http://www.alessandroalpi.net
>http://blogs.dotnethell.it/suxstellino
>http://mvp.support.microsoft.com/profile/Alessandro.Alpi
>http://italy.mvps.org

alx_81 Profilo | Guru

>A tutte le stored avevo dato le GRANT di EXECUTE, immaginando
>che il ruolo di db_datareader assegnato all'utente fosse predominante
>rispetto alle grant sulle stored. Invece ho appurato che tali
>GRANT di Execute sulle stored concedono l'esecuzione di tutto
>ciò che sta dentro alle procedure indipendentemente da ciò che
>può fare l'utente. A questo punto, correggimi se sbaglio, sono
>costretto ad individuare tutte le stored che vanno a scrivere
>sul DB e negare ad esse le GRANT di EXECUTE, giusto ?
Eh sì, io fossi in te farei un ruolo, e poi, stored per stored, darei la grant a quel ruolo, se lo pretende.
Poi l'utente farà parte del ruolo.. Ma sì, stored per stored.

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
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