1. Permission Chains

In SQL Server databases, users often access data by going through one or several objects. Ownership chains apply to views, stored procedures, and user-defined functions, for example:

• A program might call a stored procedure that then selects data from a table.
• A report might select from a view, which then selects from a table.
• A complex stored procedure might call several other stored procedures.

In these cases, the user must have permission to execute the stored procedure or select from the view. Whether the user also needs permission to select from the underlying tables depends on the ownership chain from the object the user called to the underlying tables.

If the ownership chain is unbroken from the stored procedure to the underlying tables, the stored procedure can execute using the permission of its owner. The user needs permission only to execute the stored procedure. The stored procedure can use its owner's permission to access the underlying tables. The user doesn't require permission to the underlying tables.

Ownership chains are great for developing tight security in which users execute stored procedures but aren't granted direct permission to any tables.

If the ownership chain is broken, meaning that there's a different owner between an object and the next lower object, then SQL Server checks the user's permission for every object accessed.

The EXECUTE AS clause, added in SQL Server 2005, adds flexibility to control effective permissions under which SQL Server objects are accessed in queries, stored procedures, functions, and triggers. While EXECUTE AS provides additional control capabilities, it breaks ownership chaining because the user executing the query, stored procedure, or function impersonates the specified user in the EXECUTE AS clause.

When the chain is broken, the following happens:

• The ownership chain from dbo.A to dbo.B to dbo.Person is unbroken, so dbo.A can call dbo.B and access dbo.Person as dbo.
• The ownership chain from dbo.A to Sue.C to Jose.Purchase is broken because different owners are present. Therefore, dbo.A calls Sue.C using Jose'sJose.Purchase using Jose's permissions. permissions, and Sue.C accesses
• The ownership chain from dbo.A through dbo.B to Jose.Person is also broken, so dbo.A calls dbo.B using dbo's permissions, but dbo.B must access Jose.Purchase using Jose's permissions.
• It is possible for dbo, Sue, and Jose to all have the same owner. In that case, the ownership chain works.

2. Object Ownership

An important aspect of SQL Server's security model involves object ownership. Every object is contained by a schema. The default schema is dbo — not to be confused with the dbo role.

Ownership becomes critical when permission is granted to a user to run a stored procedure when the user doesn't have permission to the underlying tables. If the ownership chain from the tables to the stored procedure is consistent, then the user can access the stored procedure and the stored procedure can access the tables as its owner. However, if the ownership chain is broken, meaning there's a different owner somewhere between the stored procedure and the table, the user must have rights to the stored procedure, the underlying tables, and every other object in between.

There is a fine point in the details: A schema is owned. And because a schema is owned, anything contained by it has the same owner.

3. Securables Permissions

The database user can be granted granular permission to specific securable objects using the Securables page of the Database Role Properties form, as shown in Figure 1.

Figure 1 The Securables page is used to grant specific permission to individual objects.

The permissions that can be granted depend on the type of object. Even databases and servers are included as a securable object, which presents several database-specific permissions.

Here is why servers need to be a securable themselves. Having server control is effectively the same as being a member of sysadmin. But if you're auditing only for membership in the sysadmin role and you're not auditing for server-level permissions, you'll never catch when a login is granted such rights. As a result, this is a prime way that attackers would seek to secure elevated access to SQL Server and attempt to keep their tracks a bit more hidden.

Unless you have a compelling reason to manage the permissions on an individual-statement level as with CREATE LOGIN or CREATE USER, it's easier to manage the database administrative tasks using the fixed database roles.

The grant, revoke, and deny commands are detailed in the next section.