Início / dba / Perguntas / 136555
Accepted
IanG
Asked: 2016-04-26 20:54:35 +0800 CST

SQL Logins na função db_owner no banco de dados não podem criar procedimentos armazenados

  • 772

Comecei a bloquear as permissões em nosso ambiente de teste removendo a permissão sysadmin de contas genéricas. A primeira conta, usada por vários desenvolvedores, é um login SQL local. Dei à conta a função db_owner no banco de dados. O desenvolvedor informa que não pode mais criar stored procedures.

Eu validei que isso é verdade nesta instância específica do SQL 2014, não posso reproduzi-lo em nenhum outro lugar. Eu fiz tudo o que posso pensar para consertar isso. A melhor pista que tenho é que criei um novo login SQL e dei a ele db_owner no mesmo banco de dados. Ele também não pode criar um procedimento. O login original não pode criar procedimentos em outros bancos de dados do usuário, mesmo que tenha db_owner .

A tentativa de criar um procedimento fornece:

Msg 262, Nível 14, Estado 18, Procedimento TheProcedure, Linha 30
Permissão CREATE PROCEDURE negada no banco de dados 'DBTest'.

A mensagem de erro está correta, CREATE PROCEDUREnão aparece para o usuário, mesmo depois de atribuí-la explicitamente. O usuário pode alterar qualquer procedimento. A criação de UDF recebe um erro semelhante:

Permissão CREATE FUNCTION negada no banco de dados...

Alguém tem alguma ideia do que pode estar acontecendo?

Quando eu faço um:

select * from fn_my_permissions(null, 'DATABASE')

CREATE PROCEDUREnão está listado. Verifiquei se há algum DENYem sys.permissions , não há nenhum.

A seguinte consulta:

SELECT * FROM fn_my_permissions('xyz', 'USER');

retorna:

IMPERSONATE, VIEW DEFINITION, ALTER, CONTROL
sql-server stored-procedures

3 respostas

  1. Best Answer

    Interessante - difícil definir este. Você já pensou em olhar para o papel público?

    sp_helprotect 'CRIAR PROCEDIMENTO', NULL, NULL,'s'

    Isso te traz de volta alguma coisa?

    • 2

  2. Ao contrário do sysadmin, que ignora as verificações, as funções de banco de dados integradas não são tão especiais que não possam ser substituídas por um DENY.

    Tente olhar para Exec sp_helpprotect Null, 'Username' e veja quais registros DENY aparecem.

    • 1

  3. Resposta curta:

    • Tente alterar o banco de dados padrão do usuário dev para seu banco de dados específico.

    • Na janela Consulta no SS Studio, verifique se eles estão usando o contexto de banco de dados correto na janela Consulta por meio da lista suspensa do banco de dados ou T-SQL USE [DBNAME].

    Resposta longa:

    Não posso falar de todas as circunstâncias, mas conheço um caso em que isso definitivamente aconteceu conosco. O banco de dados padrão foi definido como 'mestre' para nosso usuário específico e tinha direitos SA. Removemos os direitos SA e eis que de repente eles não puderam criar os procedimentos que precisavam - apenas CONNECT.

    Alterar o banco de dados padrão do usuário ajudou o banco de dados a corrigir esse problema. (Acontece que eles só tinham direitos CONNECT para o banco de dados mestre) Além disso, a instrução USE funcionou na janela SS STudio Query:

    USE DBTest
go
Create Procedure spMyProc
as
select @@servername

    Dito isso, eu verificaria o banco de dados mestre (e outros bancos de dados) para ver se os desenvolvedores colocaram erroneamente seu código em outros bancos de dados em vez do banco de dados apropriado - quando eles tinham SA. Para nós, a remoção dos direitos SA definitivamente revelou um problema brilhante em como os desenvolvedores estavam usando o sistema.

    ps Deixe-me saber se eles estão usando bancos de dados parcialmente contidos, pois pode haver usuários com nomes idênticos dentro e fora do banco de dados que causariam problemas semelhantes, aparentemente baseados em permissões.

    • 0

relate perguntas