A permissão EXECUTE é negada nos tipos de tabela definidos pelo usuário?

87

Tenho uma pergunta sobre os tipos de tabelas definidas pelo usuário no SQL Server 2008.

Para a necessidade de um dos aplicativos ASP.NET, definimos nossos próprios tipos de tabela no SQL Server 2008 para usá-los como parâmetros nos procedimentos armazenados (ao executar o comando sql no aplicativo ASP.NET, passamos o objeto DataTable como parâmetro para o procedimento armazenado veja aqui um exemplo )

O problema é que quando executamos o comando Sql (execute stored procedure) no ASP.NET, obtemos um erro:

A permissão EXECUTE foi negada no objeto 'ourTableType', banco de dados 'ourDatabase', esquema 'ourSchema'.

Por que? Por que precisamos definir permissões em tipos de tabela definidos pelo usuário? Por que não é suficiente ter permissão definida apenas no procedimento armazenado que a usa? E se temos que defini-lo não importa o quê, por que não há EXECUTEtipo de permissão para definir na janela de propriedades de qualquer natureza (eu posso ver apenas Control, References, Take Ownership, View Definition)?

O que também não entendo é que definir permissão para Controlna janela de propriedades resolve o problema e o procedimento armazenado é executado sem problemas.

— Janez
fonte

4

possível duplicata do parâmetro com valor

— Damien_The_Unbeliever

obrigado! Eu pesquisei, mas claramente não é bom o suficiente: /

— Janez

Tente colocar AS dbono final. Como esta: GRANT EXEC ON TYPE::[schema].[typename] TO [User] AS dbo. Funcionou para mim.

— Jonathan

Possível duplicata do parâmetro com valor

— LCJ

196

Eu realmente espero que você tenha resolvido isso agora, visto que a pergunta tem quase 4 meses, mas caso você não tenha resolvido, aqui está o que eu acho que é a resposta.

GRANT EXEC ON TYPE::[schema].[typename] TO [User]
GO

— mccow002
fonte

9

Meus 2 centavos: Dependendo do seu mecanismo de autenticação de conexão, você pode ter que conceder exec para o grupo Público. Portanto, sua concessão ficaria assim: GRANT EXEC ON TYPE :: [schema]. [Typename] TO [Public] GO

— Sudhanshu Mishra

@dotnetguy muito obrigado, nenhuma das soluções funcionou para mim, mas a sua.

— Mazen el Senih

3

Se o procedimento armazenado estiver usando sql dinâmico, o que significa que o @sqlé gerado e executado por meio exec @sql, você precisará de permissão concedida nas tabelas subjacentes.

Uma solução alternativa é modificar o procedimento armazenado para ser executado como um usuário diferente . Se você fizer com que seja executado como SELF, ele será executado sob o criador do procedimento armazenado, o que é extremamente perigoso. Ainda assim, se você não tiver outra opção:

CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS SELF

— rkw
fonte

1

Obrigado por apontar isso. Mas o procedimento armazenado não tem nenhum sql dinâmico nele. Apenas INSERT INTOinstruções de tabela gerais e ´UPDATE´, para as quais este usuário tem todas as permissões de que precisa. Além disso, este usuário / login é especialmente reservado / criado para esta aplicação ASP.NET para ser capaz de se conectar a este banco de dados e apenas executar procedimentos armazenados (não criar etc, o criador é sempre 'sa').

— Janez

Obrigado, esse foi o problema para mim. Outros leitores com esse problema podem consultar Permissões do SQL Server em Procs armazenados com SQL dinâmico para obter mais dicas.

— Nickolay