Ownership Chainging

In SQL Server, when an object accesses another object, and both objects have the same owner, then permissions are not checked.  This has the effect of allowing a user with permissions to an object (such as a procedure) to read and write records to a table without any permissions directly on the table.

This behavior is known as 'Ownership Chaining'.  This is a unique feature to SQL Server, no other database engine has this behavior.  The behavior is intended to skip needless checks on every execution and so is a performance feature.  SQL Server also supports cross database ownership chaining.  But this is off by-default in modern day versions of SQL Server.

The owner of a object is defaulted to the owner of the objects schema.  You can specify another owner, but this is not recommended.

An Example of ownership chaining could be:  Matt owns table [Orders] and stored procedure [CreateOrder].  Matt grants Chris permission to execute the procedures.  When Chris executes the procedure, the procedure will attempt to insert into the table.  Chris is not able to perform any direct DML to the table.  But permissions checking will be bypassed because Matt owns the procedure and the table.  The insert is allowed and the procedure completes without error.

It has some desirable and undesirable consonances.  On the positive side, users do not need direct permissions to tables.  CRUD operations can be controlled with a layer of TSQL business logic and rules.

The biggest downside is that because permissions are not check, ownership chaining can circumvent deny's.

We can also use USERS WITHOUT LOGINS and PROCEDURE SIGNING to delegate and limit permissions, whilst still allowing functionality.