Risoluzione dei problemi relativi alla visibilità dei metadati
Data aggiornamento: 14 aprile 2006
Utilizzare questo argomento per la risoluzione dei problemi di visualizzazione dei metadati.
In SQL Server 2005 un utente può vedere esclusivamente i metadati di cui è proprietario o per i quali ha ricevuto un'autorizzazione di qualche tipo. In questo modo gli utenti con privilegi minimi non possono visualizzare i metadati di tutti gli oggetti in un'istanza di SQL Server 2005. Per ulteriori informazioni sulla visibilità dei metadati, vedere Configurazione della visibilità dei metadati.
Per consentire agli utenti di visualizzare i metadati
Per consentire agli utenti con privilegi minimi di visualizzare tutti i metadati, eseguire una delle istruzioni seguenti:
GRANT VIEW ANY DEFINITION TO public;
Questa istruzione ha la priorità sulle limitazioni correlate alla visibilità dei metadati a livello di istanza. Tutti i metadati nell'istanza saranno visibili al ruolo public.GRANT VIEW DEFINITION TO public;
Questa istruzione ha la priorità sulle limitazioni correlate alla visibilità dei metadati a livello di database. Tutti i metadati nel database saranno visibili al ruolo public.GRANT VIEW DEFINITION ON SCHEMA :: <schema_name> TO public;
Questa istruzione ha la priorità sulle limitazioni correlate alla visibilità dei metadati a livello di schema. Tutti i metadati nello schema saranno visibili al ruolo public.GRANT VIEW DEFINITION ON OBJECT :: <object_name> TO public;
Questa istruzione ha la priorità sulle limitazioni correlate alla visibilità dei metadati a livello di oggetto. Tutti i metadati dell'oggetto saranno visibili al ruolo public. Se l'oggetto è una tabella, tutti gli indici, le colonne, le statistiche e i vincoli della tabella saranno visibili al ruolo public. Queste considerazioni sono valide anche per GRANT VIEW DEFINITION ON ASSEMBLY e altre istruzioni GRANT simili.
Per consentire a un utente specifico con privilegi minimi o a un ruolo di visualizzare tutti i metadati, utilizzare un nome di utente o di ruolo specifico anziché public per indicare gli utenti autorizzati.
Per consentire agli utenti di vedere altri utenti
Per impostazione predefinita, gli utenti con privilegi minimi non possono vedere altri utenti nelle viste del catalogo sys.database_principals e sys.server_principals. Questo significa che un utente con privilegi minimi che sia il proprietario di una tabella non può vedere altri utenti ai quali desidera concedere autorizzazioni. Per consentire all'utente user_X con privilegi minimi di vedere un altro utente user_Y, è possibile eseguire l'istruzione GRANT seguente:
GRANT VIEW DEFINITION ON USER :: <user_Y> TO <user_X>
Questa istruzione deve essere eseguita per ogni utente. Per automatizzare il processo, è possibile creare un trigger DDL simile al seguente:
CREATE TRIGGER grant_view_definition_on_principal ON DATABASE
FOR CREATE_USER, CREATE_ROLE
AS
DECLARE @event_type sysname, @principal_name sysname, @sql nvarchar(max);
SELECT @event_type = eventdata().value('(/EVENT_INSTANCE/EventType) [1]','sysname');
SELECT @principal_name = eventdata().value('(/EVENT_INSTANCE/ObjectName)[1]','sysname');
IF (@event_type = 'CREATE_USER')
SELECT @sql = 'GRANT VIEW DEFINITION ON USER :: ' + @principal_name + ' TO PUBLIC ' ;
ELSE
SELECT @sql = 'GRANT VIEW DEFINITION ON ROLE :: ' + @principal_name + ' TO PUBLIC ' ;
EXEC (@sql) ;
GO
Per consentire ai ruoli applicazione di accedere ai metadati a livello di server
In SQL Server 2005. poiché i ruoli applicazione non sono associati a un'entità a livello di server, un ruolo applicazione non può accedere a metadati all'esterno del database corrispondente, È possibile consentire la visualizzazione dei metadati a livello di server ai ruoli applicazione nei modi seguenti.
Impostazione di un flag di traccia
Per consentire ai ruoli applicazione di accedere ai metadati a livello di server, impostare il flag globale 4616. Per ulteriori informazioni sull'impostazione dei flag di traccia, vedere DBCC TRACEON (Transact-SQL). Per informazioni sul flag di traccia 4616, vedere Flag di traccia (Transact-SQL).
Utilizzo di una stored procedure firmata tramite certificato
È consigliabile utilizzare stored procedure firmate tramite certificato per accedere alle tabelle di sistema a livello di server. Le stored procedure firmate tramite certificato offrono i vantaggi seguenti:
- Non è necessario utilizzare un flag di traccia.
- È necessario divulgare minori informazioni a livello di server. Le applicazioni basate sui ruoli applicazione devono utilizzare le stored procedure anziché query generali. È più probabile che le stored procedure restituiscano solo i dati specifici necessari all'applicazione.
- Nell'esempio seguente viene creata una stored procedure firmata tramite certificato e illustrato l'utilizzo della stored procedure da parte di un ruolo applicazione per la visualizzazione dei metadati a livello di server.
USE master;
GO
CREATE DATABASE approle_db;
GO
CREATE LOGIN some_login WITH PASSWORD = 'SomePa$$word!';
GO
USE approle_db;
GO
CREATE USER some_user FOR LOGIN some_login;
GO
EXEC sp_addapprole 'an_approle', 'SomeAppRolePa$$word!';
GO
---------------------------------------------------------------------
-- This section shows how to use a certificate to authenticate
-- a signed procedure.
---------------------------------------------------------------------
CREATE LOGIN execute_as_login WITH PASSWORD = 'SomePa$$word!';
GO
USE master;
GO
GRANT VIEW ANY DEFINITION TO execute_as_login;
GRANT VIEW SERVER STATE TO execute_as_login;
GO
USE approle_db;
GO
CREATE USER execute_as_user FOR LOGIN execute_as_login;
GO
--
-- You must use EXECUTE AS 'authenticator' here because the application role
-- does not have a server identity. Therefore, the application role cannot use
-- the certificate permissions on the server. Therefore, you
-- need a new execution context to which you can grant
-- the needed VIEW* permissions.
--
CREATE PROC access_server_system_tables
WITH EXECUTE AS 'execute_as_user'
AS
SELECT sid, status, name, dbname, hasaccess, loginname
FROM master.dbo.syslogins;
SELECT spid, kpid, lastwaittype, waitresource, dbid
FROM master.dbo.sysprocesses;
GO
GRANT EXECUTE ON access_server_system_tables TO an_approle;
GO
CREATE CERTIFICATE signing_cert
ENCRYPTION BY PASSWORD = 'SomeCertPa$$word'
WITH SUBJECT = 'Signing Cert';
GO
BACKUP CERTIFICATE signing_cert TO FILE = 'signing_cert.cer';
GO
ADD SIGNATURE TO access_server_system_tables
BY CERTIFICATE signing_cert WITH PASSWORD = 'SomeCertPa$$word';
GO
---------------------------------------------------------------------
-- Create a copy of the signing certificate in the target
-- database. In this case, the target database is the master database.
-- This copy of the signing certificate vouches for the execution context
-- that enters this database from the signed procedure.
---------------------------------------------------------------------
USE master;
GO
CREATE CERTIFICATE signing_cert FROM FILE = 'signing_cert.cer';
GO
---------------------------------------------------------------------
-- Because the VIEW permissions in question are server-level permissions,
-- we need to grant AUTHENTICATE SERVER permission on a login-mapped certificate.
---------------------------------------------------------------------
CREATE LOGIN signing_cert_login FROM CERTIFICATE signing_cert;
GO
GRANT AUTHENTICATE SERVER TO signing_cert_login
GO
---------------------------------------------------------------------
-- Now you can open a new connection as "some_login" and
-- set the application role. Then, call the "access_server_system_tables"
-- procedure, and obtain verification that you can access server-level information
-- when the application role-based application runs.
-- For an example, see the Demo usage.sql code below.
---------------------------------------------------------------------
---------------------------------------------------------------------
-- Clean up.
-- The following statements remove the objects created above.
---------------------------------------------------------------------
USE master
GO
DROP DATABASE approle_db;
DROP LOGIN some_login;
GO
DROP LOGIN execute_as_login;
GO
DROP LOGIN signing_cert_login;
GO
DROP CERTIFICATE signing_cert;
GO
--
-- Delete the certificate file.
--
EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'xp_cmdshell', 1;
GO
RECONFIGURE;
GO
EXEC xp_cmdshell 'del "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\signing_cert.cer"';
GO
EXEC sp_configure 'xp_cmdshell', 0;
GO
RECONFIGURE;
GO
-- ============================================================================
-- - Application role access to server information - Demo usage.sql
--
-- This code is companion code that shows an example of application role access
-- to server information by using a certificate-signed procedure.
--
-- ============================================================================
-- --------------------------------------------------
-- Connect as some_login first.
-- ------------------------------------------------
USE approle_db;
GO
EXEC sp_setapprole 'an_approle', 'SomeAppRolePa$$word!';
GO
-- Display the server-level information the application role can currently view.
SELECT sid, status, name, dbname, hasaccess, loginname
FROM master.dbo.syslogins;
SELECT spid, kpid, lastwaittype, waitresource, dbid
FROM master.dbo.sysprocesses;
GO
-- Display the server-level information the application role
-- can view by running the certificate-signed stored procedure.
EXEC access_server_system_tables;
GO
Vedere anche
Attività
Risoluzione dei problemi relativi alla visibilità dei metadati delle viste partizionate distribuite
Concetti
Configurazione della visibilità dei metadati
Visualizzazione delle definizioni degli oggetti
Autorizzazione VIEW DEFINITION
Autorizzazione VIEW ANY DATABASE
Guida in linea e informazioni
Cronologia modifiche
| Versione | Cronologia |
|---|---|
14 aprile 2006 |
|