HAS_PERMS_BY_NAME (Transact-SQL)
Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure
Avalia a permissão efetiva do usuário atual em um protegível. Uma função relacionada é fn_my_permissions.
Convenções de sintaxe de Transact-SQL
HAS_PERMS_BY_NAME ( securable , securable_class , permission
[ , sub-securable ] [ , sub-securable_class ] )
securable
É o nome do protegível. Se o protegível for o próprio servidor, esse valor deverá 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).
No Banco de Dados SQL do Azure, o argumento securable_class deve ser definido com um dos seguintes valores: DATABASE, OBJECT, ROLE, SCHEMA ou USER.
permission
Uma expressão escalar não nula do tipo sysname que representa o nome da permissão a ser verificado. 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 protegível na qual a permissão é testada. O padrão é NULO.
Observação
Os subprotegíveis não podem usar colchetes no formato '[sub name]' . Em vez disso, use 'sub name' .
sub-securable_class
Uma expressão escalar opcional do tipo nvarchar(60) que representa a classe da subentidade protegível na qual a permissão é testada. O padrão é NULO.
No Banco de Dados SQL do Azure, o argumento sub-securable_class apenas é válido se o argumento securable_class é definido como OBJECT. Se o argumento securable_class for definido como OBJECT, o argumento sub-securable_class deverá ser definido como COLUMN.
int
Retorna NULL quando a consulta falha.
Esta função interna testa se a entidade de segurança 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 NULL 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 à entidade de segurança, e não negada.
Uma permissão implicada por uma permissão de nível superior mantida pela entidade de segurança, e não negada.
Uma permissão concedida a uma função ou grupo do qual a entidade de segurança é membro, e não negada.
Uma permissão mantida por uma função ou grupo de qual a entidade de segurança é 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 em nível de esquema, nomes não nulos de uma, duas ou três partes são aceitos. Para entidades em 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 nenhuma entidade de segurança em nível de servidor tenha sido criada.
A consulta a seguir retornará uma lista de classes protegíveis internas:
SELECT class_desc FROM sys.fn_builtin_permissions(default);
As ordenações a seguir são usadas:
Ordenação do banco de dados atual: protegíveis em nível de banco de dados, incluindo 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 é usado.
Ordenação do banco de dadosmaster: itens protegíveis do nível de servidor.
Não há suporte para ‘ANY’ em verificações em nível de coluna. Você deve especificar a permissão apropriada.
Aplica-se a: SQL Server 2008 (10.0.x) e posterior
SELECT HAS_PERMS_BY_NAME(null, null, 'VIEW SERVER STATE');
Aplica-se a: SQL Server 2008 (10.0.x) e posterior
SELECT HAS_PERMS_BY_NAME('Ps', 'LOGIN', 'IMPERSONATE');
SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'ANY');
Suponha que o chamador tenha a permissão IMPERSONATE na entidade de segurança Pd
.
EXECUTE AS user = 'Pd'
GO
SELECT HAS_PERMS_BY_NAME(db_name(), 'DATABASE', 'ANY');
GO
REVERT;
GO
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;
SELECT HAS_PERMS_BY_NAME
(QUOTENAME(SCHEMA_NAME(schema_id)) + '.' + QUOTENAME(name),
'OBJECT', 'SELECT') AS have_select, * FROM sys.tables
O exemplo a seguir supõe que AdventureWorks2022
é 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('AdventureWorks2022.Sales.SalesPerson',
'OBJECT', 'INSERT');
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');
Permissões (Mecanismo de Banco de Dados)
Protegíveis
Hierarquia de permissões (Mecanismo de Banco de Dados)
sys.fn_builtin_permissions (Transact-SQL)
Exibições do catálogo de segurança (Transact-SQL)