Ignore denied columns in "select * from"

Question

I need to restrict an (support) user from viewing columns in a table (other users should have full access to this table). So I granted access to only the columns I specified via "GRANT SELECT ON dbo.TestTable (FirstCol, SecondCol, ThirdCol) TO HR_Intern;"

But when I am running a "SELECT * FROM dbo.TestTable;" i got an Access Denied Error for every other column in the table. The user is doing customer support using the MSSQL Management Studio directly on the database and the errors won't allow the user to edit the data.

Is it possible to just display the columns the user have access to and ignoring every denied column?

Thanks for your help :)

Answer 1

Better to create a VIEW and provide the users access to it. In the VIEW only those columns these users can see should be part of SELECT statement.

Answer 2

As pointed out by others, you need to replace * by an explicit select list. In case you are worried about having to specify things twice, here is a query to retrieve the list of permitted columns from metadata. If you like, you can use its result set to generate (part of) the select list for the query on TestTable.

SELECT c.name
FROM sys.columns c
INNER JOIN sys.database_permissions p
    ON p.class = 1
    AND p.major_id = c.object_id
    AND p.minor_id = c.column_id
    AND p.state = 'G'
    AND p.grantee_principal_id = DATABASE_PRINCIPAL_ID('HR_Intern')
WHERE c.object_id = OBJECT_ID('dbo.TestTable')

Replace DATABASE_PRINCIPAL_ID('HR_Intern') by DATABASE_PRINCIPAL_ID() to get metadata for the currently active user.

The query is still pretty crude; it disregards table-wide grants, and all denies. You may want to experiment with that a bit.

Answer 3

No. That is how security works in SQL. Basically "SELECT *" is not good form, one is supposed to provide a field list.

If the result set would magically change based on the user logged in that would result in a lot of crappy bug reports because applications would suddenly not work. You asked for all fields, that can not be sent, hence an error report.

One workaround is to have a view with a limited number of fields and direct this user to use the views. Obviously that costs time and attention during development.