web-dev-qa-db-fra.com

La base de données ayant uniquement db_datreader affiche des propriétés non valides d'un index

Si un utilisateur de base de données SQL Server n'a que public permission dans server roles et pour une base de données particulière seulement db_datareader et public permission puis en essayant script index as CREATE To Option dans SSMS, le script généré ne sera pas correct.

Je veux dire si un index a une condition filtrée alors que la condition filtrée n'est pas affichée

Donc, pour un utilisateur qui a la permission du propriétaire script index as CREATE To montrera

USE [test]
GO

/****** Object:  Index [filtered]    Script Date: 12/30/2013 18:54:19 ******/
CREATE NONCLUSTERED INDEX [filtered] ON [dbo].[Table_1] 
(
    [b] ASC
)
WHERE ([Table_1].[b] IS NULL)
WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

Pour un utilisateur qui a seulement db_datareader autorisation script index as CREATE To montrera

USE [test]
GO

/****** Object:  Index [filtered]    Script Date: 12/30/2013 18:55:13 ******/
CREATE NONCLUSTERED INDEX [filtered] ON [dbo].[Table_1] 
(
    [b] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

Ce serait bien si un utilisateur avec db_datareader n'est pas autorisé à voir le script d'un index et affiche l'accès à l'accès refusé. Mais cela montre un script invalide. De plus, si les propriétés de l'index sont vérifiées, seules la condition filtrée ne sont pas affichées et d'autres propriétés de l'index sont affichées. Pourquoi cela se produit?

sql-serversql-server-2008-r2indexssms
6
IT researcher

C'est par conception.

Je peux comprendre pourquoi cela pourrait être déroutant de pouvoir voir des métadonnées partielles. Cependant, l'idée du rôle de données DB_Datreader est d'accorder un accès à un utilisateur à la fois aux données utilisateur ainsi qu'aux informations sur la colonne. (Vous ne seriez pas en mesure de créer une instruction SELECT si vous n'aviez pas également accès aux noms de colonne.)

Ainsi, avec cela à l'esprit, seule la partie de la définition d'index contenant des informations de colonne serait parfaitement dans les limites de l'autorisation DigneAder.

La clause d'index filtrée est toutefois considérée comme des informations de non-colonne, donc vous avez donc besoin de plus d'autorisation pour pouvoir voir également cette partie de la définition.

Vous avez besoin d'une permission de définition de la vue sur cet objet ou de la vue de toute définition pour pouvoir voir ce bit supplémentaire de métadonnées.

Je pense que ce serait bien s'ils donnent un avertissement lorsque vous générez un script de création "incomplet".

Vous pouvez le tester vous-même:

--create a database
CREATE DATABASE [testdb]
go

--change context to new database
USE [testdb]
GO

--create table
CREATE TABLE [testtable] ( col1 int, col2 int)
GO

--create filtered index
CREATE INDEX [fix_testtable_col1] ON [testtable](col1) WHERE col1 is not null
GO

--create a login
CREATE LOGIN [testlogin] WITH   PASSWORD=N'test', 
                                CHECK_EXPIRATION=OFF, 
                                CHECK_POLICY=OFF

--create a user in your database
CREATE USER [testlogin] FOR LOGIN [testlogin]

--add the user to the data reader role
EXEC sp_addrolemember N'db_datareader', N'testlogin'


--Change your execution contect to the new user with just datareader rights.
EXECUTE AS LOGIN='testlogin'

--try and view the filter definition of the index. It will not show the definition.
SELECT  name,
        has_filter, 
        filter_definition 
FROM sys.indexes
WHERE name='fix_testtable_col1'

--go back to being you
REVERT

--try and view the filter definition of the index. It will succeed.
SELECT  name,
        has_filter, 
        filter_definition 
FROM sys.indexes
WHERE name='fix_testtable_col1'

--give the user VIEW DEFINITION rights
GRANT VIEW DEFINITION ON OBJECT::testTable to testlogin

--switch context once again
EXECUTE AS LOGIN='testlogin'

--try and view the filter definition of the index. this time it will work.
SELECT  name,
        has_filter, 
        filter_definition 
FROM sys.indexes
WHERE name='fix_testtable_col1'


--don't forget to switch back to being you.
REVERT
6
Edward Dortland