Eu tenho que configurar um sistema onde UserAtenha controle quase total sobre um banco de dados (não o servidor), exceto por uma tabela que é usada pelo sa, e por isso sasempre precisará de acesso a essa tabela.
Até agora tenho:
-- executing as sa
CREATE SCHEMA [sa_schema];
CREATE TABLE [sa_schema].[table1] ( ... );
GRANT SELECT , REFERENCES ON OBJECT::[sa_schema].[table1] TO PUBLIC
CREATE USER [UserA] WITHOUT LOGIN;
GRANT CONTROL TO [UserA] WITH GRANT OPTION;
DENY ALTER , DELETE , INSERT , TAKE OWNERSHIP , VIEW CHANGE TRACKING , UPDATE
ON SCHEMA::[sa_schema] TO [UserA];
DENY ALTER ON USER::[sa] TO [UserA];
Eu pensei que isso seria suficiente, mas acontece que não é. É perfeitamente legal para UserAexecutar:
-- executing as UserA
CREATE ROLE [Denied]
DENY SELECT ON OBJECT::[sa_schema].[table1] TO [Denied]
ALTER ROLE [Denied] ADD MEMBER [sa]
E agora sanão pode mais ler a partir desta tabela.
-- executing as sa
SELECT * FROM [sa_schema].[table1]
Msg 229, Nível 14, Estado 5, Linha 2
A permissão SELECT foi negada no objeto 'table1', banco de dados 'mydb', esquema 'sa_schema'.
Claro, sapoderia consultar o banco de dados para descobrir os papéis aos quais ele foi adicionado e remover-se deles, mas isso parece um kludge e muito trabalho apenas para executar um select. Acho que poderia evitar esse problema certificando-se de UserAque não tem a capacidade de adicionar saa nenhuma função de banco de dados ou garantindo UserAque não possa modificar as permissões neste objeto, portanto, não importa quais funções saseriam adicionadas, nunca haverá um DENYsobre isso objeto.
Alguém tem alguma idéia de como garantir que sempresa terá acesso a esta tabela, independentemente de outras alterações ?UserA