Permissions issue in SSMS: “The SELECT permission

Question

Here’s the simplest repro case possible.

1. Create a brand new database. (I'm using SQL 2005.)
2. Create a login, a SQL user, and a table in the new database (see sample code below).
3. Launch SSMS and open Object Explorer, logging in as the newly-created user.
4. Attempt to open the "Tables" folder in the Object Explorer.

The Problem

Fails with this error message.

Message Text:

TITLE: Microsoft SQL Server Management Studio
Failed to retrieve data for this request. (Microsoft.SqlServer.Management.Sdk.Sfc)
For help, click: link
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
The SELECT permission was denied on the object 'extended_properties', database mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)
For help, click: link

This user can access the table and the record in the table. But the user cannot access the list of tables in Object Explorer.

SELECT USER_NAME() AS CurrentUser, col1
FROM dbo.TestTable

CurrentUser col1
----------- ----
robg_test   1000

The only work-around I have found is to give the user higher-than-necessary privileges (like db_datareader).

The Question:

What is the minimum privilege required to allow this user to open the table list in Object Explorer?

I have tried granting the user various privileges on the dbo schema, but that did not help.

Note also that I am using a SQL user simply to illustrate the problem. The original problem was with an AD user.

Here is a relatively similar question at serverfault.

---

Code

SET NOCOUNT ON
USE master
GO
IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N'robg_test')
    DROP LOGIN [robg_test]
GO
CREATE LOGIN [robg_test]
WITH
    PASSWORD         = N'CLK63!!black',
    DEFAULT_DATABASE = [RGTest],
    DEFAULT_LANGUAGE = [us_english],
    CHECK_EXPIRATION = OFF,
    CHECK_POLICY     = ON
GO

IF EXISTS (SELECT * FROM sys.databases WHERE name = 'RGTest')
    DROP DATABASE [RGTest]
GO
CREATE DATABASE [RGTest]
GO
USE [RGTest]
GO
CREATE USER [robg_test] FOR LOGIN [robg_test] WITH DEFAULT_SCHEMA = [dbo]
GO
CREATE TABLE dbo.TestTable (col1 int)
GO
GRANT SELECT ON dbo.TestTable TO [robg_test]
GO
INSERT INTO dbo.TestTable VALUES (1000)
GO

Answer 1

"By creating the SQL server db with an account, that account is owner and has all needed access"

No need for further enhancements in permissions.

This approach removed the access error which this thread seems about. I encountered the access error in SSMS, as well as Visual Studio (EF), using windows authentication and having created the SQL server DB with the Administrator account.

Practical solution for me was :

SSMS > start as administrator, sql server logon : with windows authentication - NOT to create an SQL server db - but to give an account 'create db any' permission on 'master'

then SSMS logon with that account (that has 'create db any' permissions on master) - to create the (empty) database

(VISUAL STUDIO xtra : then, in visual studio, connect to sql server with that account and compare schema's between LocalDB (source) and sql server db (target). works out well : the target db gets the schema and data content)

Answer 2

SSMS tries to get the extended properties of the table using fn_listextendedproperty. According to MSDN the required permisions to view a table's extended properties is

ALTER on table OBJECT

Your login test should have this permsision as owner of the test table (it is the owner, right?). But even if you don't have permissions on the table, the query for extended properties should return emtpy result set, not access denied. The fact that you get an access denied error on a sys object in the resource database indicates that the code signing of the system resource database (mssqlsystemresource) is broken. Did you drop any of the '##' certificates from master? did you manually altered any object in the resource database?

Anyway, you have a what looks like a corrupted instance at this moment and I'd recommend you contact product support on how to get it back into a coherent state.

Answer 3

I had similar problem and resolved that by removing two roles db_denydatareader and db_denydatawriter for that user and add other roles. I used sql management studio.

Answer 4

Please check that you didn't check db_denydatareader DB role. By removing that check it worked for me.

Answer 5

I had a similar problem. I resolved it by adding the user to the public role. But if you didn't want to do that, I also found that it could be resolved by giving the user permission to the view sys.extended-properties (in System Views within the database that you're trying to access)