Hi Cory,
I have a possible solution for you, though it does involve granting access to monProcessProcedures in a limited way.
The idea is to use a password-activated role that has been granted mon_role within a stored procedure whose source code has been hidden to secure the password. This is similar to Rob Verschoor's Granting SA rights to non-SA users method which can be found among other great material at http://www.sypron.nl
isql -Usa -P
create role secret_mon_role with passwd mysecretpassword
go
grant role mon_role to secret_mon_role
go
grant role secret_mon_role to joeuser
go
drop procedure sp_procid_dbid_lookup_proc
go
create procedure sp_procid_dbid_lookup_proc @procid int, @dbid int output
as
set role secret_mon_role with passwd mysecretpassword on
select @dbid = b.DBID
from master..monProcessProcedures a, master..monProcessProcedures b
where a.SPID = @@spid
and a.SPID = b.SPID
and a.ObjectID = @@procid
and a.ContextID = b.ContextID + 2
-- proc that called trigger was nested 2 levels above me
-- Commented out SET ROLE OFF because this raises a bogus 7768 error (CR 756892)
-- and doesn't seem to be neccessary - test on 15.7 ESD 2 with sp_activeroles
-- shows the role isn't active after we leave this proc's context
-- set role secret_mon_role off
go
grant execute on sp_procid_dbid_lookup_proc to joeuser
go
create procedure p1 as insert t1 values (1)
go
grant execute on p1 to joeuser
go
use test
go
create procedure p as insert master..t1 values (1)
go
grant execute on p1 to joeuser
go
create table t1 (x int)
go
create trigger tr1 on t1 for insert as
declare @procid_dbid int
execute sp_procid_dbid_lookup_proc @@procid, @dbid = @procid_dbid output
select @@procid, @procid_dbid, object_name( @@procid,@procid_dbid)
go
exit
isql -Ujoeuser -Pfoobar
execute p1
go