转载:Breaking ownership chaining within a schema in SQL Server
2009-12-01 14:59
295 查看
Problem
I have several objects, all in the same schema. Because of this, ownership chaining is working, as described in this previous tip. However, I don't want ownership chaining to be on, but I need the objects to remain in the same schema. How can I do this?
Solution
In SQL Server 2005/2008, the objects we typically work with, like tables, views, and stored procedures, are contained in a schema. All schemas have owners, but the objects they contain, by default, do not have owners. For instance, the table MyTable sitting in the MySchema schema doesn't have an owner, but the MySchema schema does. In these cases, SQL Server takes the owner of the schema and treats that as the owner of the object. So consider the case where you have the following objects: a table, MyTable, which is referred to by a stored procedure, MyProc.
Let's set up the scenario:
And let's create the objects in the MySchema schema:
Now, if we execute as TestUser, we'll see that the stored procedure works, because there is an ownership chain.
This is because neither MyTable nor MyProc has a specified owner. As a result, SQL Server is using the owner of the schema as the owner of both objects. Since the owner is therefore one and the same, dbo, for both objects, the ownership chain forms. Here is the result for running this query. Note: the result set is empty, because we did not insert any rows into the table.
![](http://www.mssqltips.com/tipimages2/1813_BreakingOwnershipChaining_01.jpg)
If we want the ownership chain to be broken, we need to change the owner of either the table or the stored procedure to something other than dbo, since that's the owner of the schema. We can accomplish this by either using an existing user in the database or by creating a new one and then executing an ALTER AUTHORIZATION on one of the two objects. For instance:
And now if we go back and execute the code from script 3 again as TestUser, we'll get an error. This is because there is no longer an ownership chain in effect and the TestUser database principal does not have SELECT permissions against the table:
![](http://www.mssqltips.com/tipimages2/1813_BreakingOwnershipChaining_02.jpg)
Also, if we look in SQL Server Management Studio we can see the objects are still in the same schema.
![](http://www.mssqltips.com/tipimages2/1813_k1.jpg)
So simply by changing the owner for one of the objects using ALTER AUTHORIZATION, we can break the ownership chain. This should be used with caution, however, as it is easy to overlook this when troubleshooting why something doesn't work since we're so used to having all objects within a given schema "owned" by the schema owner. Also, if the need is to only break the ownership chain on a handful of referring objects, like a few of the stored procedures, then the owner on them should be changed and not the referred to object (the table). This will ensure that other objects referencing the table will still use ownership chaining and will minimize the changes you'll need to make.
Next Steps
Refer to these other SQL Server security tips
Readers Who Read This Tip Also Read
Understanding SQL Server fixed server roles
SQL Server Security Audit Report
Dynamic SQL and Ownership Chaining in SQL Server
Script to auto generate a security report for your SQL Server instance
Granting limited permissions to create views in another schema in SQL Server - Part 2
More...
I have several objects, all in the same schema. Because of this, ownership chaining is working, as described in this previous tip. However, I don't want ownership chaining to be on, but I need the objects to remain in the same schema. How can I do this?
Solution
In SQL Server 2005/2008, the objects we typically work with, like tables, views, and stored procedures, are contained in a schema. All schemas have owners, but the objects they contain, by default, do not have owners. For instance, the table MyTable sitting in the MySchema schema doesn't have an owner, but the MySchema schema does. In these cases, SQL Server takes the owner of the schema and treats that as the owner of the object. So consider the case where you have the following objects: a table, MyTable, which is referred to by a stored procedure, MyProc.
Let's set up the scenario:
USE MSSQLTips; GO -- Create a schema to hold our objects CREATE SCHEMA MySchema AUTHORIZATION dbo; GO -- Create a user to test with CREATE USER TestUser WITHOUT LOGIN WITH DEFAULT_SCHEMA = MySchema; GO -- Create a role to assign permissions to CREATE ROLE TestRole; GO -- Add the user to the role EXEC sp_addrolemember 'TestRole', 'TestUser'; GO |
-- Create objects to show ownership chaining CREATE TABLE MySchema.MyTable (TableInt INT); GO CREATE PROCEDURE MySchema.MyProc AS BEGIN SELECT TableInt FROM MySchema.MyTable; END; GO GRANT EXECUTE ON MySchema.MyProc TO TestRole; GO |
-- script 3 EXECUTE AS USER = 'TestUser'; GO EXEC MySchema.MyProc; GO REVERT; GO |
![](http://www.mssqltips.com/tipimages2/1813_BreakingOwnershipChaining_01.jpg)
If we want the ownership chain to be broken, we need to change the owner of either the table or the stored procedure to something other than dbo, since that's the owner of the schema. We can accomplish this by either using an existing user in the database or by creating a new one and then executing an ALTER AUTHORIZATION on one of the two objects. For instance:
CREATE USER SecondOwner WITHOUT LOGIN; GO ALTER AUTHORIZATION ON OBJECT::MySchema.MyTable TO SecondOwner; GO |
![](http://www.mssqltips.com/tipimages2/1813_BreakingOwnershipChaining_02.jpg)
Also, if we look in SQL Server Management Studio we can see the objects are still in the same schema.
![](http://www.mssqltips.com/tipimages2/1813_k1.jpg)
So simply by changing the owner for one of the objects using ALTER AUTHORIZATION, we can break the ownership chain. This should be used with caution, however, as it is easy to overlook this when troubleshooting why something doesn't work since we're so used to having all objects within a given schema "owned" by the schema owner. Also, if the need is to only break the ownership chain on a handful of referring objects, like a few of the stored procedures, then the owner on them should be changed and not the referred to object (the table). This will ensure that other objects referencing the table will still use ownership chaining and will minimize the changes you'll need to make.
Next Steps
Refer to these other SQL Server security tips
Readers Who Read This Tip Also Read
Understanding SQL Server fixed server roles
SQL Server Security Audit Report
Dynamic SQL and Ownership Chaining in SQL Server
Script to auto generate a security report for your SQL Server instance
Granting limited permissions to create views in another schema in SQL Server - Part 2
More...
相关文章推荐
- (转载)The shortest, fastest, and easiest way to compare two tables in SQL Server: UNION
- Using DDL Triggers in SQL Server 2005 to Capture Schema Changes
- Understanding Object Ownership in sql 2000(how to change the schema table name in sql 2000)
- 转载:Character data is represented incorrectly when the code page of the client computer differs from the code page of the database in SQL Server 2005
- Split string in SQL Server 2005+ CLR vs. T-SQL(转载)
- [转载] Partitioning in SQL Server 2008
- [优秀英文技术文章转载]Table Value Parameters in SQL Server 2008 and .NET (C#)
- [转载]官方视频教学《XML Support in SQL Server 2005》
- Importing/Indexing database (MySQL or SQL Server) in Solr using Data Import Handler--转载
- 转载:Plan freezing and other plan guide enhancements in SQL Server 2008
- filegroup reference and partitioning scheme' is not supported in this version of sql server.
- SQLServer create schema
- Trim time in SQL server
- Missing Indexes in SQL Server 2005
- SQLServer "not in"
- Linq to SQL 语法查询(子查询 & in操作 & join )(转载)
- SQLServer "not in"
- [转]如何写出高效能TSQL -深入浅出SQL Server Relational Engine (含 SQL 2014 in-memory Engine)
- use ROW_NUMBER() for pagination in Oracle and SQLServer
- 关于sqlserver schema/user/login/role