Da un paio di giorni è in corso nel newsgroup microsoft.public.it.sql una discussione che ha come argomento la confusione esistente tra i concetti di owner, schema e permessi.
Cercando di riassumere c'è un utente che ha disegnato una base dati all'interno della quale ci sono delle viste e stored procedure che richiamano altri oggetti referenziandoli, come da best practice, anteponendo il nome dello schema al nome dell'oggetto. Questo utente ha stipulato un contratto con un noto fornitore di servizi (Aruba) che ospiterà il suo database sui propri server. Prassi consolidata di questo fornitore è quella di definire un login per l'accesso ai dati e creare, nel database dell'utente, uno schema in cui vengono creati gli oggetti che compongono il database.
In questo modo non solo viene limitata la possibilità di definire altri schema per meglio separare fra loro diverse tipologie di oggetti e/o per utilizzare gli stessi come securables, ma ogni oggetto che ne referenzia un altro smette di funzionare fino a che non vengono resi coerenti gli oggetti referenziati che adesso appartengono ad uno schema differente rispetto al momento della creazione.
Questo utente ha deciso quindi di scrivere ad Aruba, spinto anche dalla discussione scaturita nel newsgroup, chiedendo lumi sulle ragioni di una scelta tanto singolare che non solo limita le possibilità offerte dal prodotto SQL Server (non posso suddividere i miei oggetti in contenitori logici), ma crea anche disagi ai propri clienti che, se vogliono seguire le best practice in tema di "two part name" per tutti gli oggetti di database, si vedono costretti a modificare le stored procedure, le viste, le udf e le proprie applicazioni di accesso ai dati per cambiare il nome dello schema degli oggetti.
Questa è stata la risposta di Aruba:
Gentile cliente,come specificato nel supporto tecnico per l'utilizzo del servizio
http://assistenza.aruba.it/kb/idx/81/0/00002MS_Sql_Server.html
il tipo di accesso come dbo non e' consentito agli oggetti presenti nel suo db in quanto proprietario e' l'utente che le e' stato assegnato.
Inoltre cambiando l'owner dei suoi oggetti in 'dbo' di conseguenza non risulterebbero piu' accessibili in quanto l'utenza assegnata a causa di problemi di sicurezza ha specifici permessi che non sono permessi a livello di ruolo 'owner' e non possono essere cambiati.
Sono evidenti le enormi lacune sul concetto di owner, schema e permessi che ha dimostrato l'autore di questa risposta e non può essere considerata una giustificazione neanche il fatto che fino a SQL Server 2000 il concetto di owner e quello di schema erano sovrapposti.
E' infatti facilmente verificabile che a prescindere dallo schema in cui si trova un oggetto questo può essere acceduto anche se il nome dell'utente non coincide con il nome dello schema
USE master;
GO
CREATE DATABASE ArubaTest;
CREATE LOGIN Luca WITH PASSWORD = 'qwerty12345';
GO
USE ArubaTest;
GO
CREATE SCHEMA MySchema;
GO
CREATE USER Luca FROM LOGIN Luca;
GO
CREATE TABLE MySchema.T1 (ID int NOT NULL);
GO
GRANT SELECT ON MySchema.T1 TO Luca;
GO
EXECUTE AS USER = 'Luca'
SELECT ID FROM MySchema.T1
REVERT
GO
ALTER SCHEMA dbo TRANSFER MySchema.T1;
GO
GRANT SELECT ON dbo.T1 TO Luca;
GO
EXECUTE AS USER = 'Luca'
SELECT ID FROM dbo.T1
REVERT
GO
La stessa query sulla tabella T1 (adesso nello schema dbo) può essere eseguita anche se lo user in questione ha un default schema differente da dbo e non viene referenziato l'oggetto con il "two part name"
ALTER USER Luca WITH DEFAULT_SCHEMA = MySchema;
GO
EXECUTE AS USER = 'Luca'
SELECT ID FROM T1
REVERT
GO
Anche l'eventuale esigenza di creare oggetti nel database non richiede privilegi di livello dbowner. A prescindere da quale sia lo schema in cui un utente debba essere messo in grado di creare degli oggetti, l'esigenza può essere risolta con
GRANT ALTER ON SCHEMA::dbo TO Luca;
GRANT CREATE TABLE TO Luca;
GO
EXECUTE AS USER = 'Luca'
CREATE TABLE dbo.T2 (ID int NOT NULL)
REVERT
GO
Mi piacerebbe che potesse intervenire qualcuno di Aruba per meglio chiarire quella che, a mio avviso, è una risposta quantomeno lacunosa...