Re: Application of security to procs called from other procs
- From: "Arnie Rowland" <arnie@xxxxxxxx>
- Date: Wed, 9 Aug 2006 10:53:15 -0700
Security 'should' work as you desire. There is probably a configuration
problem somewhere.
Please clarify.
'Managers' are also in the 'Admin' Role, but not all members of the 'Admin'
role are 'Managers'.
The 'Admin' role has EXECUTE permission on 'uspBookingUpdate'.
For sproc 'uspRateBookingInsert', there is a [GRANT EXECUTE ON
dbo.uspRateBookingInsert TO Managers]. And there are NO other Users/Roles
with permissions allowed to EXECUTE 'uspRateBookingInsert'. (Please verify
all existing permissions on 'uspRateBookingInsert'.)
You could is the IS_MEMBER() system function with an IF block, and skip over
the sproc call to uspRateBookingInsert for those not in the 'Manager' role.
That eliminates having to deal with the error.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Chris Strug" <solace1884@xxxxxxxxxxx> wrote in message
news:ujEgMj9uGHA.4752@xxxxxxxxxxxxxxxxxxxxxxx
Hi,
I have a SQLS database connecting to Access ADP projects via unbound ADO
forms in Office 2003.
Current security set up is using Windows (integrated) authentication. All
permissions are set to Roles with server logins applied to the Roles.
Most of the time, this solution works great (even if the error messages on
the client are a little clunky). However I have noticed that a couple of
users seem to be able to run a proc that they shouldn't be able to.
I have two procs, "uspBookingUpdate" which can only be executed by users
in role "Admin" and "uspRateBookingInsert" which can only be executed by
users in the role "Managers".
The operation in question is an update of data across two tables. My
execution method is to pass all the relevant parameters to the main proc
"uspBookingUpdate". That proc updates the first table as it should and the
security applies as it should (no unauthorised execution). However, from
with-in that proc, another proc is called to update the other table
through the line:
' EXEC @RC = uspRateBookingInsert @Rate_ID, @Booking_iD, @rate,
@rate_Subcontractor, @Rate_Confirmed, DEFAULT, DEFAULT
However, the security model does *not* seem to apply here. Calling the
"uspBookingUpdate" proc seems to let users who are not in the "Managers"
role - as long as they are in the "Admin" role - execute the
"uspRateBookingInsert" proc.
Am I correct in thinking that by passing the execution of the second proc
to with-in the main proc the permissions I have created are being ignored?
Should I move the execution of the secondary proc to with-in the client?
Any and all advice is gratefully received and I hope I have made this post
clear enough!
Regards
Chris
.
- Follow-Ups:
- Re: Application of security to procs called from other procs
- From: Chris Strug
- Re: Application of security to procs called from other procs
- References:
- Application of security to procs called from other procs
- From: Chris Strug
- Application of security to procs called from other procs
- Prev by Date: Re: How to authorize a user only through an application
- Next by Date: Mixed mode user name conflict
- Previous by thread: Application of security to procs called from other procs
- Next by thread: Re: Application of security to procs called from other procs
- Index(es):
Relevant Pages
|
|
