Problema com direitos (dbowner)

Question

Galera, estou precisando executar uma proc mas estou com problema de direitos.

 

Vejam, tenho uma tabela que possui uma PK int-Identity, preciso inserir dados nesta tabela forçando o código n PK, então eu executo um "SET IDENTITY_INSERT dbo.Processo ON", só que o usuário que está executando é um usuário do AD e não é nem deve ser dbowner, isto gera um erro:

Code Block

 

Server: Msg 8104, Level 16, State 1, Procedure Stpprv_AplPROCESSOHISTORICO_Gravar, Line 34

The current user is not the database or object owner of table 'dbo.Processo'. Cannot perform SET operation

 

Como posso resolver isto, veja o meu código abaixo:

Code Block

 

SET IDENTITY_INSERT dbo.Processo_Trn on

INSERT INTO [SBNDB000].[dbo].[PROCESSO_TRN]

([IDTRN]

,[IDProcesso]

,[DataTransacao]

,[CodProcessoTipoTRN]

,[CodProcessoStatus]

,[CodTipoOrigem]

,[Observacao]

,[Login]

,[DataRegistro]

,[DelStatus])

(Select distinct P.*

from sbndb001..processo_trn P

inner join sbndb001..processo R on p.idprocesso=r.idprocesso

Where R.idprocessoespecial = @intIdProcesso

or R.idprocesso = @intIdProcesso)

 

 

Tks.

Mura

Answer 1

Boa Noite,

 

Se você estiver utilizando o SQL Server 2000, estaremos limitados a poucas alternativas:

 

- Colocar o usuário na role db_ddladmin (possibilidade de manipular instruções DDL)
- Colocar o usuário na role db_owner (todos os privilégios no banco)
- Tornar o usuário Owner da tabela (possível quebra de código e privilégios desnecessários)

 

No SQL Server 2000, independente da solução adotada, você possivelmente estará concedendo mais privilégios do que o necessário. Ainda que você tenha uma aplicação segura, o fato do usuário ser do AD possibilita uma conexão e manipulação direta no banco de dados além de significar uma violação do princípio de "menor privilégio".

 

No SQL Server 2005, temos à disposição o recurso de EXECUTE AS que funciona de uma maneira muito similar ao RunAs do Windows. Através desse recurso, você poderá executar a procedure como DBO e após sair da procedure, valem as permissões do usuário. Em outras palavras, essa instrução permitirá que você altere o contexto de execução dentro da procedure. Ex:

 

CREATE PROCEDURE uspProcedure

@intIdProcesso INT

AS

EXECUTE AS USER = 'dbo'

SET IDENTITY_INSERT dbo.Processo_Trn on

INSERT INTO [SBNDB000].[dbo].[PROCESSO_TRN]

([IDTRN]

,[IDProcesso]

,[DataTransacao]

,[CodProcessoTipoTRN]

,[CodProcessoStatus]

,[CodTipoOrigem]

,[Observacao]

,[Login]

,[DataRegistro]

,[DelStatus])

(Select distinct P.*

from sbndb001..processo_trn P

inner join sbndb001..processo R on p.idprocesso=r.idprocesso

Where R.idprocessoespecial = @intIdProcesso

or R.idprocesso = @intIdProcesso)

 

Essa implementação é exclusiva do 2005 e significa que dentro da procedure, valerão as permissões de Owner. Após a execução da procedure, o usuário voltará "a ser ele mesmo". Esse foi apenas um exemplo. Existem outras variações da procedure que podem ser igualmente interessantes (Dê uma olhada no Execute As Self e Execute As Owner).

 

[ ]s,

 

Gustavo

 

Answer 2

Estou usando SQL 2000.

 

Adicionei como você disse o usuário na role db_ddladmin e funcionou.

 

Minha dúvida qto a esta role é se por exemplo o usuário entrar via Query Analiser por exemplo, que tipo de alterações ele poderá fazer no banco/tabelas/indices/views/etc ?

 

 

Answer 3

Olá Rick,

 

Essa role permitirá que o usuário execute instrução DDL (Data Definition Language). Resumidamente, esse usuário poderá executar qualquer instrução de CREATE, ALTER ou DROP dentro do banco de dados. Ele não poderá excluir o banco, mas poderá alterar a estrutura de qualquer objeto (tabela, view, índice, procedure, etc).

 

Essa role não chega a ser tão perigosa quanto a db_owner já que o usuário também não pode ler nem alterar nenhum dado. No entanto, a possibilidade de alterar estruturas também é uma violação à segurança...

 

É uma pena que você não esteja utilizando o 2005 nesse caso. O recurso de EXECUTE AS foi feito justamente para resolver problemas como esse.

 

[ ]s,

 

Gustavo

 

Answer 4

É, eu resolvi criar um usuário SQL com direitos DDL, assim somente no momento de execução desse proc eu abro a conexão (VB.net) usando este usuário, ao final eu finalizo a conexão com o banco e o usuário continua com a conexão padrão dele, assim eu evito esse problema de segurança.

 

Vlw a ajuda ae.

Mura

Answer 5

Rick,

 

Boa solução, desta forma, fico mais seguro!!!

Answer 6

Olá Rick,

 

É uma saída, mas se você começar a ter que "operar" como db_ddladmin muitas vezes, você terá que constantemente alternar entre as conexões. Do ponto de vista de segurança, isso é aceitável, mas do ponto de vista de manutenção isso pode ser trabalhoso.

 

Você poderia considerar utilizar as Roles de aplicação (Application Role). Funcionaria da seguinte forma:

 

- O usuário se conecta normalmente (com suas credenciais de AD)
- Durante a conexão, o usuário ativa a role de aplicação (Application Role)
- A partir desse momento, todas as permissões válidas serão as da Application Role e não mais do usuário

 

Para ativar a role de aplicação, é preciso uma senha. Essa ativação fica no seu código e o usuário não saberá qual é a senha. Se ele tentar conectar diretamente, não terá nenhum permissão adicional já que só a Application Role que tem as permissões e se o usuário não poderá ativá-la sem a senha necessária.

 

Não sei se expliquei corretamente, mas se as dúvidas persistirem avise-nos.

 

[ ]s,

 

Gustavo

 

Answer 7

Cara tinha esquecido disso, puts, vou dar uma olhada aqui, nunca usei isso mas qdo fiz o curso de SQL fiz um exercício lá, vou pegar pra dar uma olhada pois é sem dúvida a melhor solução.

 

Vlw mesmo man.

Answer 8

Oi RickMura,

 

Pois é. No 2005 o EXECUTE AS resolve, mas no SQL Server 2000 temos algumas opções. Realmente a Application Role não é muito disseminada nos livros, fóruns, etc. Sua utilização é rara, mas para o seu caso acho que vem bem a acalhar.

 

Se você não conseguir localizar no MOC, avise-nos para que nós possamos ajudá-lo.

 

[ ]s,

 

Gustavo