Extended Stored Procedure Permissions Problem

I have devloped a .NET windows service to manage
server-side traces for an ongoing database auditing effort
here at work. The service creates traces, rolls them over
periodically, and loads the trace file contents into a
reporting instance. This service logs into each audited
instance using its a domain user account. The service must
call the sp_trace_create, sp_setstatus, sp_setevent, and
sp_setfilter extented stored procedures. Addtionally, it
must access the fn_trace_getinfo and fn_trace_gettable
functions.
The service works very well when the domain account is a
member of the sysadmin role in an audited instances. The
service fails to work when it is just a regular db user
with EXECUTE permissions on the above stored procedures.
The service also does not work when configured as a dbo in
the master database of the audited instance.
I am guessing that this issue arises from the trace
procedures being extended stored procedures and perhaps
there is some underlying OS permission issue. Can anyone
offer some guidance that can help me avoid running this
service as a sysadmin?
Thanks in advance,
TimIn SQL2000 you have to be a sysadmin to run trace procs. This is a change
from SQL7 where you could grant exec on the extended stored procedures
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Tim Richardson" <anonymous@.discussions.microsoft.com> wrote in message
news:dce201c40ad0$2f8e3260$a101280a@.phx.gbl...
> I have devloped a .NET windows service to manage
> server-side traces for an ongoing database auditing effort
> here at work. The service creates traces, rolls them over
> periodically, and loads the trace file contents into a
> reporting instance. This service logs into each audited
> instance using its a domain user account. The service must
> call the sp_trace_create, sp_setstatus, sp_setevent, and
> sp_setfilter extented stored procedures. Addtionally, it
> must access the fn_trace_getinfo and fn_trace_gettable
> functions.
> The service works very well when the domain account is a
> member of the sysadmin role in an audited instances. The
> service fails to work when it is just a regular db user
> with EXECUTE permissions on the above stored procedures.
> The service also does not work when configured as a dbo in
> the master database of the audited instance.
> I am guessing that this issue arises from the trace
> procedures being extended stored procedures and perhaps
> there is some underlying OS permission issue. Can anyone
> offer some guidance that can help me avoid running this
> service as a sysadmin?
> Thanks in advance,
> Tim|||Thanks, Jasper.

>--Original Message--
>In SQL2000 you have to be a sysadmin to run trace procs.
This is a change
>from SQL7 where you could grant exec on the extended
stored procedures
>--
>HTH
>Jasper Smith (SQL Server MVP)
>I support PASS - the definitive, global
>community for SQL Server professionals -
>http://www.sqlpass.org
>
>"Tim Richardson" <anonymous@.discussions.microsoft.com>
wrote in message
>news:dce201c40ad0$2f8e3260$a101280a@.phx.gbl...
>
>.
>