By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,364 Members | 1,343 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,364 IT Pros & Developers. It's quick & easy.

Securing Tables/Views

P: 48
Hi,

Is there a possibility to allow a user only for a particular view, without allowing him to open the tables directly ?

Couldn't find a way, probably overlooking. As soon reader-access is allowed on the table, the table is accesable directly, which I want to avoid

Thx

PS : I'm using Windows authentication
Jun 24 '08 #1
Share this Question
Share on Google+
9 Replies


ck9663
Expert 2.5K+
P: 2,878
Use VIEWS

Happy coding.

-- CK
Jun 24 '08 #2

P: 48
Hi,

In the URL you gave, under "Views As A Security Tool", the description matches exactly what I want to do.

My problem is, I don't get the security correct. If I don't give reader-access on the table, the view isn't useable. Meaning the table can be accessed directly via ODBC, what I don't want.

How can I restrict and have the view accessable ?

PS : I'm using SQL Server 2005
Jun 24 '08 #3

ck9663
Expert 2.5K+
P: 2,878
You can limit the access of any user to any object as long as you have the necessary rights to do so. However, if the user logging in knows the username and password of someone who have read/write access, of course he can access the tables either via ODBC or the console

-- CK
Jun 25 '08 #4

P: 48
Sure, I know that. And I have all the rights to do anything I want.

But, I'm still stuck with my question : how to give rights on a view without giving reader access on the table ?
I'm sure I'm overlooking something, so if someone could give me a clue where to do so. The "protection" tab for views doesn't allow setting the reader-access, only column-granting

What I want to achieve : only views connectable (either via application or by odbc), and only for those users (Windows-authentication) granted for the view.
Jun 25 '08 #5

ck9663
Expert 2.5K+
P: 2,878
I don't get it.

You have a table. You have users. You allow them to connect to your db. But you don't want them to see your tables? What are these users going to do with their connection anyway?

-- CK
Jun 25 '08 #6

Delerna
Expert 100+
P: 1,134
Why does it matter if they can open the table as well as the view through the odbc.
They have to connect with a user profile that you give them and if that user only has read access to the table then, even if they do open the table through the odbc, they can't do anything except read from it.
Jun 25 '08 #7

P: 9
Hi,

You need to deny permissions on the tables but allow select permission on the view. I tested this using SQL Express then using odbc and excel to test access - and it worked fine. The user logged in and could not see the tables but could see the view. The user was not a member of any group that may have select permission on the tables.
As far as I have always understood it- much of the purpose of a view is for this exact reason - to deny access to table data, as views may only contain a subset of the data, i.e. department specific/user specific. At least that is the way we use views ;-). Often users should not be allowed to even read certain table data - payroll for example, but may need a small piece of info from that table, hence a view.

JinxT.
Jun 26 '08 #8

Delerna
Expert 100+
P: 1,134
Yes its true, by connecting a user to SQLServer through some front end they can only see what is given them.
But I think the point of wquatan's question (he will correct me if I am wrong) is that by giving a user access to the table, then a user who knows what they are doing can gain access to what you didn't intend them to have, by creating their own "front end"
Jun 26 '08 #9

Expert 100+
P: 145
A stored procedure might be a good way to hide your tables yet return the information you're looking for.
Jun 30 '08 #10

Post your reply

Sign in to post your reply or Sign up for a free account.