Is a stored procedure with EXECUTE AS OWNER a valid replacement for a view selecting from third-schema tables?

Mike picture Mike · Aug 6, 2013 · Viewed 15.1k times · Source

A database user A should only have access to specific data. This data is currently provided by a view B.VIEW1 selecting from tables owned by schema B and C.

CREATE VIEW [B].[VIEW1] AS SELECT * FROM [B].[VIEW2], [C].[VIEW1]

Since C.VIEW1 is not owned by B, Ownership Chains apply.

That means although A is granted SELECT permission ON B.VIEW1, it can't select from.

SELECT permission denied on object 'C.VIEW1', database '...', schema '...'.

Is a stored procedure B.PROC1 with EXECUTE AS OWNER Clause a valid replacement for B.VIEW1 in terms of security?

CREATE PROC [B.PROC1] WITH EXECUTE AS OWNER AS BEGIN SELECT * FROM [B.VIEW2], [C].[VIEW1] END

Or are there any negative side-effects which will possibly lead to any security problems?

Answer

Mike picture Mike · Aug 9, 2013

In terms of security, this seems to be a good way to prevent access to underlying tables.

A negative side-effect is that you can't filter the resultset generated by the stored procedure by a WHERE, GROUP BY clause or similar.

But this is not that tragic if defining static constraints in an underlying view or defining "dynamic" constraints via stored proc's input parameters.

1) Static constraints in underlying view

CREATE VIEW [B].[VIEW3] AS SELECT * FROM [B].[VIEW2], [C].[VIEW1] WHERE [X]='Something' AND [Y] = GETDATE()
CREATE PROC [B].[PROC1] WITH EXECUTE AS OWNER AS BEGIN SELECT * FROM [B].[VIEW3] END

2) Dynamic constraints via input parameters

CREATE PROC [B].[PROC1] (@X varchar(30), @Y DATETIME) WITH EXECUTE AS OWNER AS BEGIN SELECT * FROM [B].[VIEW2], [C].[VIEW1] WHERE [X]=@X AND [Y]=@Y AND