Consenti all'utente di fare qualsiasi cosa all'interno del proprio schema ma non di creare o eliminare lo schema stesso


12

Ho creato uno schema in SQL Azure e concesso le seguenti autorizzazioni a un ruolo del database:

CREATE ROLE myrole AUTHORIZATION dbo;
EXEC sp_addrolemember 'myrole', 'myuser';

CREATE SCHEMA myschema AUTHORIZATION dbo;

GRANT ALTER, CONTROL, DELETE, EXECUTE, INSERT, REFERENCES, SELECT, UPDATE, VIEW 
DEFINITION ON SCHEMA::myschema TO myrole;

GRANT CREATE TABLE, CREATE PROCEDURE, CREATE FUNCTION, CREATE VIEW TO myrole;

Attraverso le autorizzazioni sopra definite è myuserpossibile creare / eliminare il proprio schema, quindi per ovviare al problema ho provato l'autorizzazione ALTER ANY SCHEMA. Ma questa autorizzazione nega anche all'utente di creare / eliminare tabelle.

Quali autorizzazioni sono necessarie per consentire all'utente di fare qualsiasi cosa all'interno del proprio schema ma non essere in grado di creare o eliminare lo schema stesso?

Risposte:


8

Non è necessario concedere CONTROLsullo schema.
L'autorizzazione richiesta DROP SCHEMAè CONTROLa livello di schema o ALTER ANY SCHEMAa livello di database ed è per questo che l'utente è stato in grado di eliminare lo schema. La rimozione di queste due autorizzazioni impedirà agli utenti associati al ruolo di creare e eliminare lo schema (a meno che non dispongano ovviamente di autorizzazioni di livello superiore).

L'autorizzazione richiesta per CREATE ALTERe DROPaltri oggetti è l' CREATEautorizzazione per il tipo di oggetto (tabella \ procedura \ funzione \ vista) combinata con l' ALTERautorizzazione sullo schema.
Hai già queste autorizzazioni nel tuo script, quindi tutto ciò che devi fare è rimuovere l' CONTROLautorizzazione. Per riferimento, ecco un elenco di istruzioni BOL inDDL cui è possibile trovare l'autorizzazione richiesta per tutti i tipi di oggetto.

Per i più pigri, ecco il tuo codice dopo aver rimosso le autorizzazioni non necessarie:

CREATE ROLE myrole AUTHORIZATION dbo;
EXEC sp_addrolemember 'myrole', 'myuser';

CREATE SCHEMA myschema AUTHORIZATION dbo;

GRANT ALTER, DELETE, EXECUTE, INSERT, REFERENCES, SELECT,
          UPDATE, VIEW DEFINITION ON SCHEMA::myschema TO myrole;

GRANT CREATE TABLE, CREATE PROCEDURE, CREATE FUNCTION, CREATE VIEW TO myrole;

Ma l'utente sarà in grado di creare oggetti anche con altri schemi?
u23432534,

4

Si noti che poiché il nuovo schema ha l'autorizzazione di "dbo", l'utente sarà in grado di accedere indirettamente a tutti gli oggetti di database in cui lo schema è di proprietà di dbo.

Esempio:

select * from dbo.test; --fails

create view myschema.test
as 
select * 
from dbo.test; --view is created

select * from myschema.test;  --contents of dbo.test now revealed.

Questo è il corretto funzionamento del motore di SQL Server; le autorizzazioni permeano in altri schemi con la stessa autorizzazione. Per limitare tale accesso, ecco un'opzione per la creazione dello schema:

CREATE SCHEMA myschema AUTHORIZATION myrole;

Questo è un ottimo punto: il proprietario dello schema è cruciale per le autorizzazioni dell'utente.
costa
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.