none
Problema com direitos (dbowner) RRS feed

  • Pergunta

  • 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

    quarta-feira, 12 de dezembro de 2007 19:38

Respostas

  • 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

     

    quarta-feira, 12 de dezembro de 2007 23:23

Todas as Respostas

  • 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

     

    quarta-feira, 12 de dezembro de 2007 23:23
  • 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 ?

     

     

    quinta-feira, 13 de dezembro de 2007 11:28
  • 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

     

    quinta-feira, 13 de dezembro de 2007 11:48
  • É, 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

    quinta-feira, 13 de dezembro de 2007 18:07
  • Rick,

     

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

    quinta-feira, 13 de dezembro de 2007 19:05
  • 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

     

    quinta-feira, 13 de dezembro de 2007 19:20
  • 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.

    sexta-feira, 14 de dezembro de 2007 12:27
  • 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

     

    sexta-feira, 14 de dezembro de 2007 15:50