Hello and thank you for your time,
I am using sql 2008
I created a db that has nothing of relevance in. Here I want to add views that access other databases. I will then add a user to the db with no relevance and give access to the view.
My obvious problem is that when the user tries to run the view, errors occur where they do not have permission to view the information. (when I use the admin type user, i can access the view and see the results no problem)
Can I create permissions to the view to all SELECT on the two seperate db's so the user can see the results. Or does the user require the read permissions on all the tables queried.
Thank you again.
This is what I tried (and many others but it did not work)
USE no-relevance-server
GRANT REFERENCES ON OBJECT[important-server::dbo.table] TO [the view]
Your issue here is one of cross database ownership chains
You can make it work by following the instructions at http://support.microsoft.com/kb/810474
EXEC sp_configure 'Cross DB Ownership Chaining', '1'; RECONFIGURE
EXEC sp_dboption 'YourDatabase', 'db chaining', 'true'
But be sure to read up about Cross Database Ownership Chaining and the associated risks.
http://msdn.microsoft.com/en-us/library/ms188676.aspx
Related
I have a database on SQL Server 2008 R2 that has two schemas, the default dbo and another one called Webapps, and both schemas are owned by dbo.
I created a view in the Webapps schema (Webapps.getInventory) that just does a simple select from dbo.Inventory. Then I created a user called Webuser that has SELECT permission to the Webapps schema.
Webuser can login and see the Webapps.getInventory view, but when it tries to select from it this error comes up:
The SELECT permission was denied on the object 'Inventory', database 'Database', schema 'dbo'.
I was thinking that since both schemas are owned by dbo, ownership chaining would allow the query to execute. The only way I seem to be able to get it to work is give Webuser permissions on dbo, or add it to the db_datareader role for the whole database. To me that seems to defeat the purpose of trying to separate things out into the Webapps schema if the user has to have read ability to everything else in the database.
So, am I overlooking something in my setup? Or is it correct that Webuser must have permission on both schemas in order for this view to work?
Eric I think you are "jumping" over a step in the ownership chain...
Have (another) look at this article: Ownership Chains Here is a snippet "Ownership chaining enables managing access to multiple objects, such as multiple tables, by setting permissions on one object, such as a view."
The chaining doesn't care that both schemas are owned by dbo, but rather that each login/user has appropriate permissions on object. So if you have a table owned by dbo that is included in a view where you have given select access to the webapps schema, then the users with access should have access to the table. The ownership chain isn't checked deeper than the fact that they can select against the view, no need to evaluate if they can select against the table.
So long story short, if you wrap the dbo.table in a view where webapps has select permissions then you should be good.
Hope that helps...
Another reason that cross-schema ownership chaining may break is if the schema owners were recently changed, e.g. setting them to the same owner specifically in order to use ownership chaining. You may need to drop and recreate the views (and add the permissions back) before it will work.
SQL Server caches various properties of views, and I saw a case where this caching appeared to be causing SQL Server to not realize that an object accessed by the view actually did have the same owner at that point. It gave a "permission denied" error on the object accessed by the view. Dropping and recreating the view fixed the problem. Rebooting the database server might have also fixed it, but that was not an option at the time.
SQL Server also allows individual objects to have specific owners different from the schema owner, and I confirmed that neither the view nor the accessed object had a separate owner set. I saw this in SQL Server 2012. Not sure if it's been fixed in newer versions.
I've got 2 databases, let's call them Database1 and Database2, a user with very limited permissions, let's call it User1, and a stored procedure in Database1, let's call it Proc1.
I grant EXECUTE permission to User1 on Proc1; GRANT EXECUTE ON [dbo].[Proc1] TO [User1] and things worked fine as long as all the referenced tables (for SELECT, UPDATE ... etc.) are in Database1, although User1 does not have explicit permission on those tables.
I modified Proc1 to SELECT from a table, let's call it Table1, in Database2. Now when I execute Proc1 I get the following error: The SELECT permission was denied on the object 'Table1', database 'Database2', schema 'dbo'
My understanding is that SQL Server will take care of the required permissions when I grant EXECUTE to a stored procedure; does that work differently when the table (or object) is in another database?
Notes:
User1 is a user in both databases with same limited permissions
I'm using SQL Server 2005
There seem to be a difference when SQL Server checks the permissions along the permission chain. Specifically:
SQL Server can be configured to allow ownership chaining between specific databases or across all databases inside a single instance of SQL Server. Cross-database ownership chaining is disabled by default, and should not be enabled unless it is specifically required.
(Source: http://msdn.microsoft.com/en-us/library/ms188676.aspx)
Late to the party, but I recommend taking a look at signed stored procedures for this scenario. They are much more secure than granting users permissions to multiple databases or turning on database ownership chaining.
... To make it possible for a user to run this procedure without
SELECT permission on testtbl, you need to take these four steps:
1.Create a certificate.
2.Create a user associated with that certificate.
3.Grant that user SELECT rights on testtbl.
4.Sign the procedure with the certificate, each time you have changed the procedure.
When the procedure is invoked, the rights of the certificate user are
added to the rights of the actual user. ...
(From http://www.sommarskog.se/grantperm.html#Certificates)
Further documentation is also available on MSDN.
Be sure that the user is actually the same in both databases. Not just NAMED the same. Try deleting the user from both databases, then create the user under the SERVER users, and assign the appropriate permissions on each database from that single user account.
To expand on #Szymon's answer with updated text from Microsoft at the end of 2018:
Ownership chaining across databases is turned off by default. Microsoft recommends that you disable cross-database ownership chaining because it exposes you to the following security risks:
Database owners and members of the db_ddladmin or the db_owners database roles can create objects that are owned by other users. These objects can potentially target objects in other databases. This means that if you enable cross-database ownership chaining, you must fully trust these users with data in all databases.
Users with CREATE DATABASE permission can create new databases and attach existing databases. If cross-database ownership chaining is enabled, these users can access objects in other databases that they might not have privileges in from the newly created or attached databases that they create.
There is also mention about dynamic SQL and certificate signing for procedures like #Rozwel mentions in their answer.
(Source: https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/enabling-cross-database-access-in-sql-server)
I've been working on giving a development team the ability to have read-only access to a SQL environment, I'm at the last step. I need them to be able to see users/logins and roles. I noticed that with view defintion granted on any given DB, it allows their login to view the users/roles for each DB, however even granted on master/msdb/model it does not allow the login to view the server wide logins/roles. What would be the best way to accomplish this? I have tried view defintion and I have tried view server state, neither has worked for server logins to be visible to the user.
Note: I don't want them to have any more access beyond that so I don't want them to be assigned a predefined role.
I'd recommend writing a stored procedure using Execute As permissions, and giving them permissions to run that. Have that stored proc output the list of users and you should be good to go.
I am not a db admin but i read an article related to setting security / permissions using schemas in sql server 2012. I tested a little for setting permissions to some views.
This might help http://msdn.microsoft.com/en-us/library/dd283095.aspx
I am using SQL Server 2008 Express edition.
I have created a Login , User, Role and Schema.
I have mapped the user to the login, and assigned the role to the user.
The schema contains a number of tables and stored procedures.
I would like the Role to have execute permissions on the entire schema.
I have tried granting execute permission through management studio and through entering the command in a query window.
GRANT EXEC ON SCHEMA::schema_name TO role_name
But When I connect to the database using SQL management studio (as the login I have created) firstly I cannot see the stored procedures, but more importantly I get a permission denied error when attempting to run them.
The stored procedure in question does nothing except select data from a table within the same schma.
I have tried creating the stored procedure with and without the line:
WITH EXECUTE AS OWNER
This doesn't make any difference.
I suspect that I have made an error when creating my schema, or there is an ownership issue somewhere, but I am really struggling to get something working.
The only way I have successfully managed to execute the stored procedures is by granting control permissions to the role as well as execute, but I don't believe this is the correct, secure way to proceed.
Any suggestions/comments would be really appreciated.
Thanks.
There are couple of issues that I can see in your case.
First of all you would need View Definition granted for you to be able to see the objects in the Management studio.
I would recommend this if you want the role to have all permissions,
GRANT EXECUTE, SELECT, INSERT, UPDATE, DELETE, VIEW DEFINITION
ON Schema::SchemaName TO [RoleName/LoginName]
Also make sure the owner of your user-defined schema is "dbo".
This is my setup:
SQL server 2005
UserA already setup as user on the server but not on databaseA.
GRANT Execute ON [GetOrders] TO [UserA] AS [dbo]
As you can see, i have missed out a step. I haven't added UserA to the database yet. This doesn't fail and lets me grant execute on the object.
I believe in 2000 it would have thrown an error and not allowed me to do this.
Now, I have all these objects with the correct permissions set but the users cannot see the database. To resolve this i have to remove the users from the database, re-add them properly and then give permissions.
Why is this allowed and is there a way to either prevent it or have it create the db login automatically whenever a new user is given object permissions.
thanks.
This is the part throwing you off.
TO [UserA] AS [dbo]
Ditch the "as dbo" part. It's granting the right to the dbo user. Without the "AS [dbo]" part it will throw an error.
It's probably allowed to give DBAs the flexibility to modify the users and permissions when the database is not attached to your production server. I don't believe you have to re-add the users. Take a look at this guy's script: http://www.lazycoder.com/weblog/2007/06/04/re-associate-sql-users-with-logins/