Compartilhar via

  • Artigo

HAS_PERMS_BY_NAME (Transact-SQL)

Avalia a permissão efetiva do usuário atual em um protegível. Uma função relacionada é fn_my_permissions.

Ícone de vínculo de tópicoConvenções de sintaxe Transact-SQL

Sintaxe

HAS_PERMS_BY_NAME ( securable , securable_class , permission  
        [ , sub-securable ] [ , sub-securable_class ] )

Argumentos

  • securable
    É o nome do protegível. Se o protegível for o próprio servidor, esse valor deve ser definido como NULL. securable é uma expressão escalar do tipo sysname. Não há nenhum padrão.

  • securable_class
    É o nome da classe do protegível na qual a permissão é testada. securable_class é uma expressão escalar do tipo nvarchar(60).

  • permission
    Uma expressão escalar não nula do tipo sysname que representa o nome da permissão a ser verificada. Não há nenhum padrão. O nome da permissão ANY é um curinga.

  • sub-securable
    Uma expressão escalar opcional do tipo sysname que representa o nome da subentidade do protegível na qual a permissão é testada. O padrão é NULL.

    ObservaçãoObservação

    Nas versões do SQL Server até o SQL Server 2008 Service Pack 2, subprotegíveis sub não podem usar colchetes no formato '[nome do sub]'. Use 'nome do sub'.

  • sub-securable_class
    Uma expressão escalar opcional do tipo nvarchar(60) que representa a classe da subentidade do protegível na qual a permissão é testada. O padrão é NULL.

Tipos de retorno

int

Retorna NULL quando a consulta falha.

Comentários

Esta função interna testa se o principal atual tem uma permissão efetiva específica em um protegível especificado. HAS_PERMS_BY_NAME retorna 1 quando o usuário tem permissão efetiva no protegível, 0 quando o usuário não tem nenhuma permissão efetiva no protegível e quando a classe protegível ou permissão não é válida. Uma permissão efetiva é qualquer uma das permissões a seguir:

  • Uma permissão concedida diretamente ao principal e não negada.

  • Uma permissão indicada por uma permissão de nível mais alto mantida pela entidade, e não negada.

  • Uma permissão concedida a uma função ou um grupo do qual a entidade é membro, e não negada.

  • Uma permissão mantida por uma função ou um grupo do qual a entidade é membro, e não negada.

A avaliação da permissão sempre é executada no contexto de segurança do chamador. Para determinar se algum outro usuário tem uma permissão efetiva, o chamador deve ter a permissão IMPERSONATE nesse usuário.

Para entidades do nível de esquema, nomes não nulos de uma, duas ou três partes são aceitos. Para entidades do nível de banco de dados, um nome de uma parte é aceito, com um valor nulo que significa “banco de dados atual”. Para o servidor propriamente dito, um valor nulo (que significa “servidor atual”) é obrigatório. Essa função não pode verificar permissões em um servidor vinculado ou em um usuário do Windows para o qual nenhum principal do nível de servidor tenha sido criado.

A consulta a seguir retornará uma lista de classes de protegíveis internos:

   SELECT class_desc FROM sys.fn_builtin_permissions(default)

Os agrupamentos a seguir são usados:

  • Agrupamento do banco de dados atual: protegíveis do nível de banco de dados que incluem protegíveis não contidos por um esquema, protegíveis com escopo no esquema de uma ou duas partes; banco de dados de destino quando um nome de três partes for usado.

  • Agrupamento do banco de dados master: protegíveis do nível de servidor.

  • As verificações do nível de coluna não oferecem suporte para ‘ANY’. Você deve especificar a permissão apropriada.

Exemplos

A. Tenho a permissão VIEW SERVER STATE do nível de servidor?

SELECT HAS_PERMS_BY_NAME(null, null, 'VIEW SERVER STATE');

B. Posso usar a permissão IMPERSONATE no principal Ps de servidor?

SELECT HAS_PERMS_BY_NAME('Ps', 'LOGIN', 'IMPERSONATE');

C. Tenho alguma permissão no banco de dados atual?

SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'ANY');

D. O principal Pd de banco de dados tem alguma permissão no banco de dados atual?

Suponha que o chamador tem a permissão IMPERSONATE no principal Pd.

EXECUTE AS user = 'Pd'
GO
SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'ANY');
GO
REVERT;
GO

E. Posso criar procedimentos e tabelas no esquema S?

O exemplo a seguir requer a permissão ALTER em S e a permissão CREATE PROCEDURE no banco de dados; de modo similar para tabelas.

SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE PROCEDURE')
    & HAS_PERMS_BY_NAME('S', 'SCHEMA', 'ALTER') AS _can_create_procs,
    HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'CREATE TABLE') &
    HAS_PERMS_BY_NAME('S', 'SCHEMA', 'ALTER') AS _can_create_tables;

F. Em quais tabelas eu tenho a permissão SELECT?

SELECT HAS_PERMS_BY_NAME
(QUOTENAME(SCHEMA_NAME(schema_id)) + '.' + QUOTENAME(name), 
    'OBJECT', 'SELECT') AS have_select, * FROM sys.tables;

G. Tenho a permissão INSERT na tabela SalesPerson em AdventureWorks?

O exemplo a seguir supõe que AdventureWorks é meu contexto de banco de dados atual e usa um nome de duas partes.

SELECT HAS_PERMS_BY_NAME('Sales.SalesPerson', 'OBJECT', 'INSERT');

O exemplo a seguir não faz nenhuma suposição sobre meu contexto de banco de dados atual e usa um nome de três partes.

SELECT HAS_PERMS_BY_NAME('AdventureWorks.Sales.SalesPerson', 
    'OBJECT', 'INSERT');

H. Em quais colunas da tabela T eu tenho a permissão SELECT?

SELECT name AS column_name, 
    HAS_PERMS_BY_NAME('T', 'OBJECT', 'SELECT', name, 'COLUMN') 
    AS can_select 
    FROM sys.columns AS c 
    WHERE c.object_id=object_id('T');