permissão para create/alter procedure

[Socorro Vieira]

Pessoas,

 

Preciso dar permissão para um usuário criar e alter procedure sem alterar outros objetos.

Dei grant em create procedure e alter, mas é  claro que ele pode alterar qualquer objeto do schema dbo e isso não me atende.

Não posso dar ddladmin, securityadmin ou dbowner.

Qual seria minha opção para resolver este problema? Create procedure e alter, porém tirando permissão dos demais objetos que ele não precisa poderia ser uma opção?

Alguém tem outra ideia? 

 

 

Abraços, 
--
Socorro Vieira

[Rodrigo Ribeiro]

Utiliza Module Signing

[Rodrigo]

Ops, confundi sua pergunta... Module Signing nao atenderia...

Eu tambem ja tentei algo parecido... o foda é que create e alter sao a niveis de schema...

Uma das solucoes que já vir por ai, conceder a permissao de ALTER, mas criar uma trigger DDL que impeça o alter em outros objetos...

Se for 2008, como Policy Based Managment fica mais fácil, acredito eu.

[Raionan Andrade]

Boa tarde Socorro..

Assim?

GRANT CONTROL ON SCHEMA::[dbo] TO [user]

GO

grant CREATE PROCEDURE TO [user]

GO

[Socorro Vieira]

Só que com control, você dá permissão pro usuario alterar tabela, por exemplo.

E eu só quero que ele crie e altere procedure.

Mas eu já resolvi o problema. Valeu!

 

 

2011/8/3 Raionan Andrade <rai...@gmail.com>

Boa tarde Socorro..

Assim?

GO

Em 2 de agosto de 2011 22:36, Rodrigo <rrbb...@gmail.com> escreveu:

Ops, confundi sua pergunta... Module Signing nao atenderia...

Eu tambem ja tentei algo parecido... o foda é que create e alter sao a niveis de schema...

Uma das solucoes que já vir por ai, conceder a permissao de ALTER, mas criar uma trigger DDL que impeça o alter em outros objetos...

Se for 2008, como Policy Based Managment fica mais fácil, acredito eu.

--
Socorro Vieira

[Bruno Martins]

Socorro, 

e qual foi a solução ???

--
Bruno de Melo Martins
http://nomundosql.blogspot.com

Os investimentos em conhecimento geram os melhores dividendos.

                       Benjamin Franklin

[Socorro Vieira]

Bruno,

 

A solução que eu encontrei foi permissão de create procedure, grant alter nas procedures existentes e deny alter nos demais objetos.

 

Att,

Socorro Vieira

2011/8/3 Bruno Martins <brunom...@gmail.com>

[Raionan Andrade]

É um boa solução, o que ferra do sql não ter algo pronto é só a manutenção..

[Socorro Vieira]

É, não tem não...

=//

2011/8/3 Raionan Andrade <rai...@gmail.com>

--
Socorro Vieira

[Gustavo Maia]

Boa Noite,

 

De fato é uma limitação. O máximo que você conseguiria é criar uma SP que cria SPs e usar um EXECUTE As, mas sinceramente... Tenho minhas dúvidas. No caso do CONTROL sem tão "perigoso", talvez o ALTER dê uma amenizada. Segue um exemplo:

 

-- Cria um banco de dados

CREATE

DATABASE B

-- Muda o contexto

USE

B

-- Cria um usurio

CREATE

USER Usr WITHOUT LOGIN

-- Cria uma SP

CREATE

PROCEDURE P1 As SELECT 1

GO

-- Cria uma tabela

CREATE

TABLE T (ID INT)

-- Concede permisso de criao e alter de SPs para Usr

-- Concede um GRANT para o Schema dbo (supostamente onde a SP ficar)

GRANT

CREATE PROCEDURE TO Usr

GRANT

ALTER ON SCHEMA::dbo TO Usr

-- Muda o contexto de execuo

EXECUTE

As USER = 'Usr'

-- Verifica que o contexto foi trocado

SELECT

USER_NAME()

-- Cria uma SP nova

CREATE

PROCEDURE P2 As SELECT 2

GO

-- Altera a SP antiga

ALTER

PROCEDURE P1 As SELECT 0

-- Exclui a SP antiga (efeito colateral mesmo sem o DROP)

DROP

PROCEDURE P1

-- Tenta dropar a tabela (efeito colateral mesmo sem o DROP TABLE)

DROP

TABLE T

-- Tenta criar uma tabela (essa no funcionou)

CREATE

TABLE T (ID INT)

-- Reverte o contexto

REVERT

-- Dropa o usurio

DROP

USER Usr

-- Muda o contexto

USE

master

-- Dropa a base

DROP

DATABASE B

 

[ ]s,

 

Gustavo

2011/8/3 Socorro Vieira <socorr...@gmail.com>