Re: SQL 2000 Sproc Role security bypassed when using QBF?
- From: Erland Sommarskog <esquel@xxxxxxxxxxxxx>
- Date: Mon, 9 Jul 2007 22:03:17 +0000 (UTC)
Alec MacLean (alec.maclean@xxxxxxxxxxxxxxxxxxx) writes:
I should add that the dynamically built Varchar is run using the syntax
"Execute(@theVCstring)".
I am aware I can reduce my admin by adding to the existing role, or
creating an additional new role that manages the direct table select
permissions (I don't need or want to let the app use db_datareader), but
I wonder why the EXECUTE function requires the additional SELECT
permission that sprocs normally inherit?
Because the ownership chain is broken. Access to tables through stored
procedures relies on the fact that the stored procedure and the tables
have the same owner. But a batch of dynamic SQL does not have any owner.
Since you are on SQL 2000, you are stuck. On SQL 2005 there are other means
to grant permissions through stored procedures than ownership chaining.
If you are curious, I have an article on my web site about these method.
This article also discusses ownership chaining in more detail.
http://www.sommarskog.se/grantperm.html.
--
Erland Sommarskog, SQL Server MVP, esquel@xxxxxxxxxxxxx
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
.
- References:
- SQL 2000 Sproc Role security bypassed when using QBF?
- From: Alec MacLean
- Re: SQL 2000 Sproc Role security bypassed when using QBF?
- From: Alec MacLean
- SQL 2000 Sproc Role security bypassed when using QBF?
- Prev by Date: Re: Complete Neophyte Question(s)
- Next by Date: Re: Access Sql server 2005 from .net class library
- Previous by thread: Re: SQL 2000 Sproc Role security bypassed when using QBF?
- Next by thread: Re: Access Sql server 2005 from .net class library
- Index(es):
Relevant Pages
|