Logo - tutorial.programming4.us
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

SQL Server 2005 : Privilege and Authorization - Ownership Chaining

7/24/2011 4:53:05 PM
The most common method of securing SQL Server resources is to deny database users any direct access to SQL Server resources and provide access only via stored procedures or views. If a database user has access to execute a stored procedure, and the stored procedure is owned by the same database user that owns a resource being referenced within the stored procedure, the user executing the stored procedure will be given access to the resource, via the stored procedure. This is called an ownership chain.

To illustrate, start by creating and switching to a test database:

CREATE DATABASE OwnershipChain
GO

USE OwnershipChain
GO

Now, create two database users, Louis and Hugo:

CREATE USER Louis
WITHOUT LOGIN
GO

CREATE USER Hugo
WITHOUT LOGIN
GO


Note that both of these users are created using the WITHOUT LOGIN option, meaning that although these users exist in the database, they are not tied to a SQL Server login and therefore no one can authenticate as one of them by logging in to the server. This option is one way of creating the kind of proxy users mentioned previously.

Once the users have been created, create a table owned by Louis:

CREATE TABLE SensitiveData
(
IntegerData INT
)
GO

ALTER AUTHORIZATION ON SensitiveData TO Louis
GO

At this point, Hugo has no access to the table. To create an access path without granting direct permissions to the table, a stored procedure could be created, also owned by Louis:

CREATE PROCEDURE SelectSensitiveData
AS
BEGIN
SET NOCOUNT ON

SELECT *
FROM dbo.SensitiveData
END
GO

ALTER AUTHORIZATION ON SelectSensitiveData TO Louis
GO

Hugo still has no permissions on the table at this point; the user needs to be given permission to execute the stored procedure:

GRANT EXECUTE ON SelectSensitiveData TO Hugo

At this point Hugo can execute the stored procedure, thereby selecting from the table. However, this only works because Louis owns both tables, and both are in the same database; if either of those conditions were not true, the ownership chain would break, and Hugo would have to be authorized another way to select from the table. The ownership chain would also fail if the execution context changed within the stored procedure. For example, ownership chaining will not work with dynamic SQL.

In the case of a stored procedure in one database requesting access to an object in another database, it is possible to maintain an ownership chain, but it gets quite a bit more complex, and security is much more difficult to maintain. To set up cross-database ownership chaining, the user that owns the stored procedure and the referenced table(s) must be associated with a server-level login, and each database must have the DB_CHAINING property set using the ALTER DATABASE command. That property tells SQL Server that either database can participate in a cross-database ownership chain, either as source or target—but there is no way to control the direction of the chain, so setting the option could open up security holes inadvertently.

I recommend that you avoid cross-database ownership chaining whenever possible, and instead call stored procedures in the remote database. Doing so will result in a more secure, more flexible solution. For example, moving databases to separate servers is much easier if they do not depend on one another for authentication. In addition, with the inclusion of schemas in SQL Server 2005, splitting objects into multiple databases is no longer as important as it once was. Consider avoiding multiple databases altogether, if at all possible.
 
Other -----------------
- SQL Server 2005 : Privilege and Authorization - Basic Impersonation Using EXECUTE AS
- Configuring Standard Permissions for Exchange Server 2010 (part 2) - Understanding & Assigning Advanced Exchange Server Permissions
- Configuring Standard Permissions for Exchange Server 2010 (part 1)
- Feature Overview of Microsoft Lync Server 2010 : Dial-In Conferencing & Enterprise Voice
- Feature Overview of Microsoft Lync Server 2010 : Instant Messaging & Web Conferencing
- Feature Overview of Microsoft Lync Server 2010 : Presence
- Installing Windows Small Business Server 2011
- Business Server 2011 : Planning Fault Tolerance and Avoidance - Disk Arrays
- Microsoft Dynamics GP 2010 : Improving financial reporting clarity by splitting purchasing accounts & Speeding up lookups with Advanced Lookups
- Microsoft Dynamics GP 2010 : Remembering processes with an Ad hoc workflow
 
 
Top 10
- Microsoft SQL Server 2012 : Knowing Tempdb - Troubleshooting Common Issues (part 3) - Troubleshooting Space Issues
- Microsoft SQL Server 2012 : Knowing Tempdb - Troubleshooting Common Issues (part 2) - Latch Contention - ikelihood of it happening. Multiple Tempdb Data Files
- Microsoft SQL Server 2012 : Knowing Tempdb - Troubleshooting Common Issues (part 1) - Latch Contention - Allocation Page Contention
- Microsoft SQL Server 2012 : Knowing Tempdb - Overview and Usage (part 2) - The Version Store
- Microsoft SQL Server 2012 : Knowing Tempdb - Overview and Usage (part 1) - User Temporary Objects
- Microsoft Lync Server 2013 : Windows Client - Navigating in the Client - Useful Lync Client Shortcuts
- Microsoft Lync Server 2013 : Windows Client - Navigating in the Client - Managing Contacts, Managing Groups, Status View
- Microsoft Lync Server 2013 : Windows Client - Navigating in the Client - Configuring Basic Options
- Microsoft Lync Server 2013 : Windows Client - Installing the Client
- Microsoft Exchange Server 2013: Configuring mailbox delivery restrictions, permissions, and storage limits (part 4) - Setting storage restrictions on mailbox and archives
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone