Securing Tables/Views

Use VIEWS

Happy coding.

-- CK

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

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

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.

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

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.

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.

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"

A stored procedure might be a good way to hide your tables yet return the information you're looking for.