Sandro Bizioli


Chi sogna di giorno conosce molte cose che sfuggono a chi sogna soltanto di notte. (E.A.Poe)
Mappa

Autorizzazioni restrittive

Sappiamo tutti che in SQL Server è possibile autorizzare o meno uno User ad effettuare determinate operazioni su di un oggetto, tabella o sp che sia.
Infatti, una volta creata ad esempio una tabella, è necessario impostare i permessi ai vari utenti affinchè possano effettuare select o modificarne i dati.
Potremmo ad esempio autorizzare un utente al solo inserimento ed aggiornamento dei dati su una tabella, escludendogli la possibilità di fare una select. Concettualmente non ci sono problemi, ma in pratica questo potrebbe darci qualche grattacapo.
Facciamo un esempio.

Dopo essermi loggato con un utente autorizzato a creare tabelle ed assegnare permessi (ad esempio sa) creo la situazione che mi serve.
set nocount ON;
-- Creo un nuovo Database
USE master;
GO
IF DB_ID (N'mytest') IS NOT NULL
DROP DATABASE mytest;
GO
CREATE DATABASE mytest;
GO
--Creo un nuovo utente
EXEC sp_addlogin @loginame='UserProva', @PassWd='1UserPrv', @defdb='myTest'
GO
-- Mi sposto sul nuovo database
Use myTest
GO
-- Aggiungo il nuovo utente al database myTest
EXEC sp_adduser @loginame='UserProva', @name_in_db='UserProva'
GO
-- Definisco la tabella myTable
CREATE TABLE myTable
        (
        Codice varchar(6) NOT NULL,
        Descrizione varchar(25) NOT NULL,
        Flag bit NULL
        )  ON [PRIMARY]
GO
-- Inserisco alcuni valori
insert into mytable(codice, descrizione) values ('SB', 'Sandro')
insert into mytable(codice, descrizione) values ('LB', 'Luca')
insert into mytable(codice, descrizione) values ('AM', 'Andrea')
insert into mytable(codice, descrizione) values ('GH', 'Gianluca')

-- Attribuisco i diritti alla tabella
grant update on myTable to UserProva
grant Insert on myTable to UserProva
GO
set nocount OFF

Ora mi loggo con il nuovo utente e provo a fare delle operazioni:
-- Provo ad inserire i dati
INSERT INTO mytable(codice, descrizione) VALUES ('NW', 'New')
GO
UPDATE myTable SET flag = 1 WHERE codice ='NW'
/*
Msg 229, Level 14, State 5, Line 2
SELECT permission denied on object 'myTable', database 'mytest', schema 'dbo'.
*/

Il messaggio mi segnala un'autorizzazione negata sulla SELECT? Ma io ho fatto un UPDATE?
Già, ma nell'update avevo specificato la clausola where che implica la necessità di leggere i dati per poter localizzare i record interessati e, quindi, di disporre anche del permesso di esecuzione sulla select.
La prova del nove la possiamo ottenere eseguendo l'update senza clausola where.
UPDATE myTable SET flag = 1 

Come premesso nessun problema.
I permessi e le autorizzazioni sono molto potenti, ma vanno gestiti con un pizzico di attenzione altrimenti si incappa inevitabilemente in errori come questo.

Prima di salutarvi ripuliamo il nostro database
USE master
GO
sp_droplogin 'UserProva'
GO
DROP DATABASE mytest
GO
Categoria: SQL Server
mercoledì, 01 mar 2006 Ore. 12.05
Statistiche
  • Views Home Page: 109.884
  • Views Posts: 560.136
  • Views Gallerie: 108.933
  • n° Posts: 227
  • n° Commenti: 222
Copyright © 2002-2007 - Blogs 2.0
dotNetHell.it | Home Page Blogs
ASP.NET 2.0 Windows 2003