SQL Server Storage Engine : SQL Server Security
Tags: SQL Server Security

• Fun with execution context switching
  

  Having multiple users each owning various objects is commonplace in the database world. When one user wants to give access of their object to another user -- that’s when administration of databases gets rather interesting.

   

  Consider the following SQL Server 2000 experience: 

  • User Barney has a table of Rock and Roll hits
  • User Fred wrote a stored procedure that accepts a time period and returns a list of the hits of that year

  In the current scenario, Fred needs at least SELECT access to Barney's table in order for the stored procedure to work. This seems like a logical administrative task. 

   

  Now suppose Wilma wants to use Fred's stored procedure.  In SQL Server 2000, Wilma would need explicit access to Barney's table or Fred would have to own the table in order for Wilma to accomplish this.  Now imagine trying to manage this for hundreds of users in an enterprise and you can see that managing all these permissions could be quite cumbersome unless we came up with some consistent strategy.

   

  To help alleviate some of this administrative burden, SQL Server 2005 allows users the ability to specify the execution context of which an object like a stored procedure or user-defined function will run under.

   

  Imagine in our scenario that Fred could say, when this stored proc executes, execute it under my credentials so that Wilma doesn't have to go and get permissions on everything within the stored procedure in order for her to use it.

   

  In SQL Server 2005, this would be accomplished using EXECUTE AS OWNER.  In fact there are four possibilities when it comes to changing the execution context.  They are as follows:

   

  EXECUTE AS CALLER– This will execute under the credentials of the caller.  This is the same default behavior as in previous versions of SQL Server.  I.e. when Wilma calls the stored proc, the proc runs under Wilma.

   

  EXECUTE AS SELF– This will execute under the credentials of the user who last modified the stored procedure.  In our scenario if Bam-Bam modified Fred's stored proc and Wilma called Fred's Proc, the proc would run under Bam-Bam.

   

  EXECUTE AS ‘(insert name of login)’– This will execute under the credentials of the login identified.  In order for this to work, the user creating or modifying the stored procedure needs to have IMPERSONATE permission for the login specified.  In our scenario if Fred wanted to run the stored proc under Dino's credentials, Fred would need the IMPERSONATE permissions granted to him by the sysadmin first, then he could EXECUTE AS 'Dino'.

   

  EXECUTE AS OWNER– This will execute under the credentials of the login who owns the stored procedure.  As explained previously, Fred's stored proc will be run under Fred regardless of who executes it.

   

  Referring back to our example, let us write a few examples of execution context switching. To gain the most from this, it is best to walk through this line by line in your favorite TSQL editor or simply read through the comments.

  -- Demo setup

  -- create our logins, users and database

  use master

  go

  createlogin BarneyLogin with password='!@w9Kfvn3'

  createlogin FredLogin with password='MN3@8YU8u'

  createlogin WilmaLogin with password='Nb29D%&2j'

  go

  createdatabase Music

  go

  use Music

  go

  --Create our database users mapped to their login

  createuser BarneyUser forlogin BarneyLogin with default_schema=BarneySchema

  createuser FredUser forlogin FredLogin with default_schema=FredSchema

  createuser WilmaUser forlogin WilmaLogin with default_schema=WilmaSchema

  go

  --Create our schemas for each user

  createschema BarneySchema

  authorization BarneyUser

  go

  createschema FredSchema

  authorization FredUser

  go

  createschema WilmaSchema

  authorization WilmaUser

  go

  --Create a table that Barney's schema owns

  use Music

  go

  createtable BarneySchema.RockHits

  (YearPublished intNOTNULL,

  Title