Question

Is it possible to change execution context to CALLER in a stored procedure, which is created with EXECUTE AS OWNER? Here is what I mean with a simplified example:

There are several logins and databases in a server instance. Assume that everybody has a table named current_work in his own database, but nobody can access to no other s table. Even the Boss isn t allow to access to the employees databases, unless an employer decides that his table is ready for the Boss to see. When the employer thinks his work is done, he is supposed to commit its table contents to Boss database. However, the Boss doesn t want to allow his employers to INSERT anything into his table, because there is a kind of business logic he wants to implement (let s say he wants to log the commits somewhere). So he wants this to happen only under his control, i.e. within an SP he wrote. He writes an SP like below, creates users in his database for each of the logins (for each employee), and then gives GRANT EXECUTE for this SP to all his employers. When an employee is done, he just calls this SP, and everything should be fine:

CREATE PROCEDURE boss.dbo.commit_work
WITH EXECUTE AS OWNER AS
BEGIN
   EXECUTE AS CALLER  -- It should be OK, since this is the default way of calling an SP anyway, thinks the boss
   SELECT * INTO ##tmptable FROM current_work  -- No prefix should mean default DB/Schema of the caller, thinks the boss
   REVERT  -- Back to OWNER s context, which happens to be the boss

   INSERT INTO boss.allwork
   SELECT * FROM ##tmptable
END

However, things doesn t go as he expected. The employers can execute the SP, but they get an error saying The server principal "Boss" is not able to had access the database "boss" under the current security context. , which makes the boss very upset (BTW Boss is the Login for the boss.)

Do you have an idea of what went wrong? Or do you see another way of implementing such a scenario, in which nobody is supposed to access to no other s DB unless the execution happens in the SP? I would have done such a thing in application level, when I had had the choice, but I am bound to database level because of the requirements of our current environment. Thanks!

Answer 1

I found the answer here in this great article of Erlang Sommarskog "Giving Permissions through Stored Procedures". I recommend you to read the whole article to grasp the idea.. All I had to do was creating a local proxy user and giving it the appropriate rights:

CREATE USER boss_proxy WITHOUT LOGIN
GRANT INSERT ON boss.allwork TO boss_proxy 

CREATE PROCEDURE boss.dbo.commit_work
WITH EXECUTE AS boss_proxy AS
BEGIN
   EXECUTE AS CALLER  -- It IS OK, indeed
   SELECT * INTO ##tmptable FROM current_work  -- No prefix means default DB/Schema of the caller
   REVERT  -- Back to boss_proxy s context

   INSERT INTO boss.allwork
   SELECT * FROM ##tmptable
END

友情链接