SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Give a user access to ONE table


Give a user access to ONE table

Author
Message
Mike Hinds
Mike Hinds
SSC Eights!
SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)

Group: General Forum Members
Points: 994 Visits: 1107
What's the safest way, not necessarily the most elegant, to grant a user account read-only access to only one table in a database? The total number of tables may change over time.

I've tried various tests with REVOKE ALL TO Public, creating custom roles, etc., but not satisfied (and failed to create comfort level in the business unit) so far.

Mike Hinds
Senior Database Administrator
1st Source Bank
MCP, MCTS
Toby White
Toby White
Right there with Babe
Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)

Group: General Forum Members
Points: 755 Visits: 639
GRANT SELECT ON [Schema Name].[Table Name] to [Principal Name]

I guess you tried this but the user has access to objects through other groups/roles. What you are trying to do cannot be done by design. I suggest doing an active directory and permission audit to see exactly what users and groups have what permissions and then working with Network support to clean this up. Nested groups can make this more difficult, but power shell and/or other scripting can help.

If you are a domain admin you can just look all this up, but if not then scripts can help. For example the following VBS script will tell you what members are in a group assuming there are groups with access to your database:

Set Arg = WScript.Arguments
set oGroup = GetObject("WinNT://datacore_kc/"+Arg(0)+",group")
for each oMem in oGroup.Members
str = str + oMem.name + chr(9) + oMem.Class + chr(10)
next
msgbox(str)
Mike Hinds
Mike Hinds
SSC Eights!
SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)

Group: General Forum Members
Points: 994 Visits: 1107
What we finally did was:

EXEC sp_msForEachTable 'DENY SELECT ON ? TO [TheUser]'
GO

GRANT SELECT ON [dbo].[AllowedTable] TO [TheUser]
GO


For anyone considering this, sp_msForEachTable is "non-supported".

Mike Hinds
Senior Database Administrator
1st Source Bank
MCP, MCTS
Toby White
Toby White
Right there with Babe
Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)Right there with Babe (755 reputation)

Group: General Forum Members
Points: 755 Visits: 639
I see. I guess if that's what you were dealing with you could have just as easily generated the script with

SELECT 'DENY SELECT ON [' + s.name + '].[' + t.name + '] To [TheUser]'
FROM sys.tables t
JOIN sys.schemas s
ON t.Schema_id = s.Schema_id
UNION
SELECT '[dbo].[AllowedTable] TO [TheUser]'
Rich Mechaber
Rich Mechaber
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1551 Visits: 3665
Mike Hinds (9/9/2010)
What we finally did was:

EXEC sp_msForEachTable 'DENY SELECT ON ? TO [TheUser]'
GO

GRANT SELECT ON [dbo].[AllowedTable] TO [TheUser]
GO


For anyone considering this, sp_msForEachTable is "non-supported".


But what happens when you add another table in the future and haven't removed the user from whatever group has given him access? The user will then have access to the new table, no?

Rich
Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62450 Visits: 19102
First, don't grant rights to a user. If there's one, he/she will be replaced, or you'll add someone else. Take 10sec and write

Create role MyDenyRole




Then I'd do a GRANT on the single table to that role

If the user doesn't have rights to the database, that's all that's needed. They don't get rights to other tables by default. If they have rights from another role, then you will need some DENY statements, and you'll have to handle that, or remove them from the other group/role.

DO NOT grant rights to public. It's a bad idea. If you have rights set on public, create another role, transfer rights, remove them from public.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Mike Hinds
Mike Hinds
SSC Eights!
SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)

Group: General Forum Members
Points: 994 Visits: 1107
rmechaber (9/10/2010)
Mike Hinds (9/9/2010)
What we finally did was:

EXEC sp_msForEachTable 'DENY SELECT ON ? TO [TheUser]'
GO

GRANT SELECT ON [dbo].[AllowedTable] TO [TheUser]
GO


For anyone considering this, sp_msForEachTable is "non-supported".


But what happens when you add another table in the future and haven't removed the user from whatever group has given him access? The user will then have access to the new table, no?

Rich


You're exactly right, Rich. This was my big objection to this method. The database belongs to a 3rd party app, and tables will not change until the app gets an upgrade. The only thing is, the programmers who need this access expect me to remember to tell the engineer who is in charge of upgrades, that my script needs to be run AFTER the vendor's upgrade is complete.

Mike Hinds
Senior Database Administrator
1st Source Bank
MCP, MCTS
Mike Hinds
Mike Hinds
SSC Eights!
SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)

Group: General Forum Members
Points: 994 Visits: 1107
Steve Jones - Editor (9/10/2010)
First, don't grant rights to a user. If there's one, he/she will be replaced, or you'll add someone else. Take 10sec and write

Create role MyDenyRole




Then I'd do a GRANT on the single table to that role

If the user doesn't have rights to the database, that's all that's needed. They don't get rights to other tables by default. If they have rights from another role, then you will need some DENY statements, and you'll have to handle that, or remove them from the other group/role.

DO NOT grant rights to public. It's a bad idea. If you have rights set on public, create another role, transfer rights, remove them from public.


First, I apologize - I failed to mention that this "user" is a native SQL service account, not a human. It will never change (unless I'm able to remove it at some point). Because of this, I believe the role is an unnecessary layer.

I agree in not doing anything with public. Trouble is, public already has read/write. As soon as a (new, naked) user account is added to the DB, it inherits read/write from public. It would make my life easier if public didn't come fully loaded.

Mike Hinds
Senior Database Administrator
1st Source Bank
MCP, MCTS
robert.dour
robert.dour
Grasshopper
Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)

Group: General Forum Members
Points: 13 Visits: 4
After reading a few articles and trial and error, the only procedure that worked was using
sp_msForEachTable.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search