SQL Stored Procedure permission chain issue

I have a stored procedure that selects a field(ufilter) from a table.  The ufilter field contains a clause to use in a where statement to filter the records returned to the caller.  Example of contents of ufilter:  make='Oldsmobile'  .  The sp then should read the  content of the cars table, based on the the dymanically generated select statement

I grant Execute rights on the spGetCars stored procedure.  Runs fine when I execute it from my account.  However, when I use a less privileged account, tells me that select is not granted on Cars table.

I grant execute rights to the spGetCars for a less privilieged windows logon.  As the Cars table has the same owner (dbo) as the stored procedure, shouldn't the permission chain allow selecting from the Cars table without explicitly granting the select rights on the Cars table to the less privilieged windows logon account?

Thank you for any assitance you can provide.

spGetCars
 
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
go
 
 
ALTER proc [dbo].[spGetCars]
(
@uid varchar(30)
)
as
 
set nocount on
 
DECLARE @ufilter varchar(200)
DECLARE @uexpdate datetime
DECLARE @cmd varchar(200)
 
 
select @ufilter=ufilter, @uexpdate=uexpdate from UFILTERS where uid=@uid
 
 
IF ISNULL(@ufilter, 'ZZTOP') = 'ZZTOP'
	BEGIN
		select * from Cars where 1 = 2
	END
 
IF @ufilter = 'NONE'
	BEGIN
		select * from Cars order by Make, Model
	END
ELSE
	BEGIN
		set @cmd = 'select * from Cars where ' + @ufilter
		exec (@cmd)
	END

Open in new window

JEClarkAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
dzex13Connect With a Mentor Commented:

You need explicitly grant select permissions to the table Cars for the "less privileged"account and this should solve the problem.
0
 
JEClarkAuthor Commented:
Thank you for the input.  I agree that solves the problem but is it necessary to explicitly grant the less privileged account select permission on the table Cars?  My understanding is that the execute permissions the less privlieged account on the stored procedure has should mean that it can select from the Cars table as the sp is using the table.  Thanks again.
0
 
Anthony PerkinsConnect With a Mentor Commented:
>> My understanding is that the execute permissions the less privlieged account on the stored procedure has should mean that it can select from the Cars table as the sp is using the table.<<
Nope.  That is the biggest drawback to using Dynamic SQL:  You need to give prmissions to any action in the Dynamic SQL.

Most people focus on the bad performance when using Dynamic SQL and overlook the fact that by its very nature and the permissions you have to grant it is a major security flaw.  To the point that in many shops it is not even allowed.
0
 
JEClarkAuthor Commented:
Thank you for clearing this up.  This certainly is a drawback in using dynamic SQL
0
 
Anthony PerkinsCommented:
For such a simple Stored Procedure there is probably no need to use Dynamic SQL.  Feel free to ask a new question as to how you can convert that to get away from using Dynamic SQL.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.