Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / General / Security / March 2008

Tip: Looking for answers? Try searching our database.

EXECUTE AS question

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
stavros - 12 Mar 2008 22:36 GMT
Hi,

I posted this in the server group, but haven't gotten help, so i
thought I should try the security group.  I'm trying to give my users
the ability to run sp_who2 on SQL 2005 and
see all sessions, without granting them additional permissions.  I
thought I could do something like this:

CREATE PROCEDURE [dbo].[sp_who2_all]
WITH EXECUTE AS SELF
AS
EXEC sp_who2

The procedure creates successfully, and it does execute under a
different security context - I can see this because the login column =
sa.  However, it only returns one record, for the current session only
(as it would for a user without the VIEW SERVER STATE permission).  Of
course, if I connect as sa and run sp_who2, I see information from all
sessions.

To be clear, if I log in as sa, sp_who2 returns all sessions (as
expected).  The SP
above does in fact execute as sa (as expected).  However, it
still only lists the current session, as if it's executing without the
VIEW SERVER STATE perm.  That's the piece I don't understand, and what
I need a solution for.

Why is it behaving this way, and is there a good workaround?  Is this
only my environment?  If someone could confirm the behaviour, that
might help.

Thanks -  stavros
Erland Sommarskog - 13 Mar 2008 00:16 GMT
> The procedure creates successfully, and it does execute under a
> different security context - I can see this because the login column =
[quoted text clipped - 9 lines]
> VIEW SERVER STATE perm.  That's the piece I don't understand, and what
> I need a solution for.

This because when you impersonate a user, you are sandboxed into the
current database, unless that database is marked as trustworthy.

An alternative solution is to sign the procedure with a certificate,
and then associate create a login for the certificate, and then grant
that login VIEW SERVER STATE.

I have an article on my web site that covers this in detail:
http://www.sommarskog.se/grantperm.html

Signature

Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

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

stavros - 19 Mar 2008 21:32 GMT
> > The procedure creates successfully, and it does execute under a
> > different security context - I can see this because the login column =
[quoted text clipped - 24 lines]
> Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
> Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

Thanks, Erland!  I had read your excellent article, but apparently not
carefully enough.  I was able to follow your advice of signing the
procedure with a certificate, and it works beautifully.

Stavros
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.