none
Permissão de usuario RRS feed

  • Pergunta

  • Preciso dar permissão pra um usuario de sistema poder ter acesso a trigger, estive olhando permissão por permissão e não consegui identificar nenhuma que libere.

    Li na internet sobre a View Definition. Mas tenho minhas duvidas antes de aplicar queria consultar com algum de vocês. 

    Quero dar permissão em select, insert, delete, update, executar procs, triggers w views.

    quarta-feira, 14 de março de 2012 14:40

Respostas

  • Adalvitor, não desista.

    Vamos fazer uma analogia para que tu possa tentar confrontar o gerente de TI.

    Você terá o papel de DBA, ele é o Gerente de TI.

    Tu pode chegar um dia no trabalho e demitir um Analista que tu não ache necessário?

    Não! Porque? Porque este não é o teu papel na hierarquia da empresa.

    Tu não PODE fazer isso, porque o teu cargo não tem esse GRANT. Imagina se tu tivesse esse GRANT e demitisse alguém acidentalmente. Qual o custo deste erro?

    O mesmo é com o banco de dados e com tudo em sistemas de informação.

    O princípio é NÃO TER ACESSO, depois se concede permissão para cada nova necessidade. Se fizer o contrário perde-se controle e perde-se a organização.

    Outro ponto. O teu Analista de sistema deveria dizer exatamente quais as permissões necessárias para execução do software.

    Ele desenvolveu toda uma estrutura de banco de dados, desenhada sob um software, e as permissões devem ser estabelecidas.

    Quando se desenvolve um sistema se cria os papéis de cada usuário e nisso se cria um perfil, ele tem que te passar os perfis que precisa para o software, seja select, insert, update, delete onde for preciso.

    Obviamente não conheço a estrutura organizacional da tua empresa, mas em muitas empresas o maior valor da empresa, são seus dados, quanto custa as informações da empresa? É como dar a chave de um cofre para todo mundo, isso é dar grant de DBA para todos.

    Mesmo que não seja acessado este usuário, somente configurado na aplicação, os usuários tem que ter apenas as permissões que precisam, não se da super poderes para quem não deve usá-los.

    Espero que ajude.

    Marque a resposta caso seja útil, vlew.


    --
    Marcus Vinícius Bittencourt
    blog: isqlserver.wordpress.com
    www.sqlserverRS.com.br

    • Marcado como Resposta Adalvitor terça-feira, 20 de março de 2012 17:51
    terça-feira, 20 de março de 2012 16:24

Todas as Respostas

  • Adalvitor,

    Para que o usuário possa ter acesso e executar um trigger é necessário que ele tenha permissão de Grant para Select, Insert, Update e Delete a tabela que contem este trigger vinculado.

    Por padrão as permissão são atribuídas ao objeto ao qual o trigger esta vinculado.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quinta-feira, 15 de março de 2012 19:59
    Moderador
  • Adalvitor, explica melhor o que tu precisa.

    O View Definition te da permissões de consulta aos metadados, mas não te da permissão ao próprio protegível.

    Tu não terá nem SELECT nem CONTROL, ou seja, não vai ver os dados das tabelas, mas vai ver os objetos.

    Qual exatamente tua necessidade, e como o Junior comentou a trigger afeta uma determinada tabela, tu terá que ter permissão nela para que a trigger execute sem problemas.

    Espero que ajude.


    --
    Marcus Vinícius Bittencourt
    blog: isqlserver.wordpress.com
    www.sqlserverRS.com.br

    sexta-feira, 16 de março de 2012 12:51
  • Ola Marcus e Junior

    Então basicamente o que eu quero é que as trigger funcionem quando do banco de dados funcionem....por que eu criei um usuário para o ERP acessar o meu banco de dados, dei permissão DML e select nesse usuário, só que depois me chamaram falando que o sistema tava dando erro pra rodar um trigger, quando fui ver, tava falando que o usuário não tinha permissão para a trigger tal.

    segunda-feira, 19 de março de 2012 18:18
  • Então Adalvitor, basta ver o que esta trigger faz, insert, select, update, delete e dar estas permissões nas tabelas que estiver trabalhando.

    A partir dai a trigger deve funcionar perfeitamente, não tem como dar permissão na trigger para execução, ela simplesmente vai fazer alguma coisa.

    Esta alguma coisa é que tu tens que liberar, seja insert, update, delete ou select mesmo.

    Espero que ajude, vlew.


    --
    Marcus Vinícius Bittencourt
    blog: isqlserver.wordpress.com
    www.sqlserverRS.com.br

    segunda-feira, 19 de março de 2012 18:57
  • Boa Marcus entendi então...se eu der permissão de select,update,insert e delete as triggers irão funcionar por que é ação que ela vai tomar será uma delas. Functions se aplicado mesmo jeito ?

    Procedures é só permissão de execute.

    Você por acaso tem algum tipo permissão padrão que vc da para um usuário de sistema?

    Eu sempre dei permissão select,update,delete,insert e execute.

    segunda-feira, 19 de março de 2012 19:08
  • Opa Adalvitor, 

    Função é um poco diferente de tabelas.

    Permissões de função escalar são EXECUTE, REFERENCES e permissões de função com valor de tabela são DELETE, INSERT, REFERENCES, SELECT, UPDATE.

    Quanto a permissão padrão não existe, tudo vai depender de como ele tem que se portar no teu sistema, o que ele deverá fazer...

    Da uma olhada nesse link, fala bastante sobre quais grants em quais objetos.

    http://msdn.microsoft.com/en-us/library/ms188371.aspx

    Espero que ajude.

    Vlew.


    --
    Marcus Vinícius Bittencourt
    blog: isqlserver.wordpress.com
    www.sqlserverRS.com.br

    terça-feira, 20 de março de 2012 14:20
  • Oi Marcus

    Eu já tinha dado uma lida nesse documento, fiz pergunta de padrão de usuário para sistema, por que eu estava em uma guerra com o gerente da Ti de onde trabalho, por que ele quer q o usuário do sistema tenho permissão owner no banco, eu disse que não pode, por que esse usuário teria permissão de DBA no banco de poder fazer o que quiser, mas ele bate na mesma tecla que esta assim e nunca deu nada então não é pra mudar por que o ERP precisa de um usuário que tenha acesso completo. Ai meio que to quase desistindo.

    terça-feira, 20 de março de 2012 15:33
  • Adalvitor, não desista.

    Vamos fazer uma analogia para que tu possa tentar confrontar o gerente de TI.

    Você terá o papel de DBA, ele é o Gerente de TI.

    Tu pode chegar um dia no trabalho e demitir um Analista que tu não ache necessário?

    Não! Porque? Porque este não é o teu papel na hierarquia da empresa.

    Tu não PODE fazer isso, porque o teu cargo não tem esse GRANT. Imagina se tu tivesse esse GRANT e demitisse alguém acidentalmente. Qual o custo deste erro?

    O mesmo é com o banco de dados e com tudo em sistemas de informação.

    O princípio é NÃO TER ACESSO, depois se concede permissão para cada nova necessidade. Se fizer o contrário perde-se controle e perde-se a organização.

    Outro ponto. O teu Analista de sistema deveria dizer exatamente quais as permissões necessárias para execução do software.

    Ele desenvolveu toda uma estrutura de banco de dados, desenhada sob um software, e as permissões devem ser estabelecidas.

    Quando se desenvolve um sistema se cria os papéis de cada usuário e nisso se cria um perfil, ele tem que te passar os perfis que precisa para o software, seja select, insert, update, delete onde for preciso.

    Obviamente não conheço a estrutura organizacional da tua empresa, mas em muitas empresas o maior valor da empresa, são seus dados, quanto custa as informações da empresa? É como dar a chave de um cofre para todo mundo, isso é dar grant de DBA para todos.

    Mesmo que não seja acessado este usuário, somente configurado na aplicação, os usuários tem que ter apenas as permissões que precisam, não se da super poderes para quem não deve usá-los.

    Espero que ajude.

    Marque a resposta caso seja útil, vlew.


    --
    Marcus Vinícius Bittencourt
    blog: isqlserver.wordpress.com
    www.sqlserverRS.com.br

    • Marcado como Resposta Adalvitor terça-feira, 20 de março de 2012 17:51
    terça-feira, 20 de março de 2012 16:24