Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
simondeutsch
Aged Yak Warrior
547 Posts |
 Posted - 2004-06-03 : 13:51:28
|
| Can someone please clarify how permissions on views works? Do they overrride the base table permissions, etc.Sarah Berger MCSD |
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2004-06-03 : 14:08:27
|
| I wouldn't say permissions are overridden, but if a user has say select permissions to the view, then the user can select from the view regardless if the user doesn't have permissions on the tables in the view. I wouldn't recommend permissions on objects though except for stored procedures.Tara |
 |
|
|
simondeutsch
Aged Yak Warrior
547 Posts |
Posted - 2004-06-03 : 21:00:21
|
| I'm aware of vertical/horizontal partitioning in views, and restricting the columns. Question as follows:There are views that exist basically as a sort of optimized query, in other words, they are not there to partition the data for security or performance, but rather exist because it is so much faster than an ad-hoc query.The problem is that users that have all permissions on the base tables but none on the views are getting errors.Now, should I give SELECT permissions on all views to the public role if not all users should have access to this data? But OTOH, if I don't, when the client adds a user or role, they won't be able to access these views either without explicitly granting permissions to them.A possible solution would be that when a new role is added, a stored procedure should run that grants SELECT on all views, but again, that would be like giving SELECT on all views to Public. And the clients don't have the capabilities for setting up permissions on views. Any ideas?Sarah Berger MCSD |
|
|
|
|
|
|
|
|
Permissions on views