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.

user permissions

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Trapulo - 10 Mar 2008 11:42 GMT
How can I allow a user to see single database size, and kill process on that
DB, without make it "sysadmin", on SQL 2005?

thanks
Uri Dimant - 10 Mar 2008 13:18 GMT
Hi
Is she/he an owner of db? db_owner role.

> How can I allow a user to see single database size, and kill process on
> that DB, without make it "sysadmin", on SQL 2005?
>
> thanks
Trapulo - 10 Mar 2008 15:53 GMT
yes, he's dbo but it seems that he cannot make this kind of operations...

> Hi
> Is she/he an owner of db? db_owner role.
[quoted text clipped - 3 lines]
>>
>> thanks
Rick Byham, (MSFT) - 10 Mar 2008 17:10 GMT
To kill processes you can make the person a member of the process admin
fixed server role. However that would give the KILL process permission in
every database. Essentially, connections are a server thing, not a database
thing, so you can't give out that permission on a single database.
Signature

Rick Byham (MSFT)
This posting is provided "AS IS" with no warranties, and confers no rights.

> yes, he's dbo but it seems that he cannot make this kind of operations...
>
[quoted text clipped - 5 lines]
>>>
>>> thanks
Charles Wang[MSFT] - 11 Mar 2008 03:50 GMT
Hi Trapulo,
I would like to add some comments regarding 'EXECUTE AS' clause in SQL
Server 2005 as a complement of Rick's response. I think you can work around
this issue by creating a stored procedure with 'EXECUTE AS' clause in SQL
Server 2005.  

First ensure that the account specified in the EXECUTE AS clause has the
permission to kill a process; then in the stored procedure, you can use
"exec xp_cmdsehll 'kill <pid>'" to kill a process; finally give out
permissions to execute the stored procedure for your database user. By this
way, you should be able to not only do the database thing but also do the
server thing.

For more information, please refer to:
EXECUTE AS Clause (Transact-SQL)
http://msdn2.microsoft.com/en-us/library/ms188354.aspx

Hope this helps. If you have any other questions or concerns, please feel
free to let us know. Have a nice day!

Best regards,
Charles Wang
Microsoft Online Community Support
===========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@microsoft.com.
===========================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for
non-urgent issues where an initial response from the community
or a Microsoft Support Engineer within 1 business day is acceptable.
Please note that each follow up response may take approximately
2 business days as the support professional working with you may
need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by
contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
============================================================
Signature

This posting is provided "AS IS" with no warranties, and confers no rights.

=========================================================
Ola Hallengren - 12 Mar 2008 01:31 GMT
>you can use "exec xp_cmdsehll 'kill <pid>

We are talking about killing a sql connection, so xp_cmdshell isn't a
solution, is it?

I thought about doing something with EXECUTE AS in a stored procedure and
then checking that it's the right database before killing the connection, but
I'm not sure how that would work with the security as the kill sql command is
outside the scope of the database.

Ola Hallengren
http://ola.hallengren.com

> Hi Trapulo,
> I would like to add some comments regarding 'EXECUTE AS' clause in SQL
[quoted text clipped - 45 lines]
> This posting is provided "AS IS" with no warranties, and confers no rights.
> =========================================================
Charles Wang[MSFT] - 12 Mar 2008 10:47 GMT
Hi Ola,
Thanks for your response.
Originally I just noticed that Trapulo said he wanted to kill processes on
that DB, so I did not think of killing connections.

Anyway I would like to add more comments regarding both killing a process
and a connection. For killing a process, I just found that kill.exe is not
guaranteed to be  on all the existing Windows operating systems. For a
common usage, you may write a script file and then execute it via
cscript.exe. For example:
====Killproc.vbs=================
If Wscript.Arguments.Count = 0 Then
   Wscript.Echo "You must enter a PID."
   Wscript.Quit
End If

intPID = Wscript.Arguments.Item(0)

strComputer = "."
Set objWMIService = GetObject _
   ("winmgmts:\\" & strComputer & "\root\cimv2")
Set colProcessList = objWMIService.ExecQuery _
   ("Select * from Win32_Process Where ProcessID = " & intPID & "")
For Each objProcess in colProcessList
   objProcess.Terminate()
Next
==============================
If you save it in drive C:, then you can run cscript.exe to execute it. In
SQL Server, you can use the following statement:
exec xp_cmdshell 'cscript c:\killproc.vbs 7640'

Regarding killing a connection, you need to ensure that your login account
has the fixed server roles: sysadmin and processadmin. I performed a test
with the following statements:
create procedure usp_killsession(@spid int)
as
begin
execute as LOGIN='mylogin_with_sysadmin_processadmin_fixed_server_roles'
declare @strSQL nvarchar(200)
set @strSQL = N'KILL ' + CAST(@spid as nvarchar(20))
exec sp_executeSQL @strSQL
REVERT
end

For your concerns of checking connections on a database, you can use the
DMVs sys.dm_exec_connections and sys.dm_exec_sessions.

You may also refer to:
KILL (Transact-SQL)
http://msdn2.microsoft.com/en-us/library/ms173730.aspx

Hope this helps. Welcome your any other suggestions or concerns. Have a
nice day!

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@microsoft.com.
=========================================================
Signature

This posting is provided "AS IS" with no warranties, and confers no rights.

=========================================================
Ola Hallengren - 12 Mar 2008 13:27 GMT
The question is what permissions that is needed to execute the stored
procedure?

/Ola

> Hi Ola,
> Thanks for your response.
[quoted text clipped - 62 lines]
> This posting is provided "AS IS" with no warranties, and confers no rights.
> =========================================================
Charles Wang[MSFT] - 12 Mar 2008 14:10 GMT
Any user who is granted EXECUTE on the stored procedure can execute the
stored procedure. This is not a problem to Trapulo, his user was a dbo.
Please feel free to let me know if you have any different opinions. Thank
you!

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@microsoft.com.
=========================================================
Signature

This posting is provided "AS IS" with no warranties, and confers no rights.

=========================================================
Ola Hallengren - 12 Mar 2008 18:33 GMT
I understand it as the login that is calling the stored procedure also needs
to have IMPERSONATE rights on the login in question.

GRANT IMPERSONATE ON LOGIN::LoginThatIsProcessAdmin TO
[LoginThatIsExecutingTheStoredProcedure]

I have done some tests that support this.

Without the IMPERSONATE rights you get an error message.
"Cannot execute as the server principal because the principal
"LoginThatIsProcessAdmin" does not exist, this type of principal cannot be
impersonated, or you do not have permission.".

(This means that the login could in reality do an EXECUTE AS outside the
stored procedure and kill any connection.)

Ola Hallengren
http://ola.hallengren.com

> Any user who is granted EXECUTE on the stored procedure can execute the
> stored procedure. This is not a problem to Trapulo, his user was a dbo.
[quoted text clipped - 13 lines]
> This posting is provided "AS IS" with no warranties, and confers no rights.
> =========================================================
Charles Wang[MSFT] - 13 Mar 2008 12:59 GMT
Hi Ola,
Thanks for your response.

My appologies for not carefully testing this, yes, you are right.
IMPERSONATE permission must be granted on the login account with sysadmin
and processadmin to the limited login account.

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@microsoft.com.
=========================================================
Signature

This posting is provided "AS IS" with no warranties, and confers no rights.

=========================================================
Ola Hallengren - 13 Mar 2008 20:14 GMT
Another option is to mark a database (e.g. master) as trustworthy and create
a stored procedure WITH EXECUTE AS OWNER.

Erland Sommarskog has an article on his web site about this.
http://www.sommarskog.se/grantperm.html

Ola Hallengren
http://ola.hallengren.com

> Hi Ola,
> Thanks for your response.
[quoted text clipped - 15 lines]
> This posting is provided "AS IS" with no warranties, and confers no rights.
> =========================================================
Charles Wang[MSFT] - 14 Mar 2008 08:17 GMT
Yes, that is also an option for impersonation. Just one thing I want to
point out since TRUSTWORTHY is at database level, it may impact other UDFs
and SPs who do not need an impersonation context. EXECUTE AS clause is
still the first priority here.

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@microsoft.com.
=========================================================
Signature

This posting is provided "AS IS" with no warranties, and confers no rights.

=========================================================
Ola Hallengren - 18 Mar 2008 18:48 GMT
Let's look at the problem again.

A user should be able to kill connections only for a specific database.

We've come up with the solution to make a stored procedure that is checking
the connections dbid, before killing the connection.

1. About the security we could do an EXECUTE AS LOGIN in the stored
procedure. We then have to grant IMPERSONATE rights.

The problem with this is that the user could easily bypass the logic in the
stored procedure, by doing an EXECUTE AS LOGIN and then kill any connection.

2. We could also create the stored procedure WITH EXECUTE AS OWNER and mark
the database as TRUSTWORTHY. You're right that you have to be very careful
with this. One solution could be to create the stored procedure in the master
database (or a custom admin datatabase) and mark that database as TRUSTWORTHY.

Ola Hallengren
http://ola.hallengren.com

> Yes, that is also an option for impersonation. Just one thing I want to
> point out since TRUSTWORTHY is at database level, it may impact other UDFs
[quoted text clipped - 13 lines]
> This posting is provided "AS IS" with no warranties, and confers no rights.
> =========================================================
Erland Sommarskog - 18 Mar 2008 23:54 GMT
> A user should be able to kill connections only for a specific database.

And in the end the user who is causing he mess in database B may have
database A as his current database, and is now running a cross-database
query...

> 2. We could also create the stored procedure WITH EXECUTE AS OWNER and
> mark the database as TRUSTWORTHY. You're right that you have to be very
> careful with this. One solution could be to create the stored procedure
> in the master database (or a custom admin datatabase) and mark that
> database as TRUSTWORTHY.

Or sign the procedure with a certificate, and create a login from this
certificate, and add this login to the processadmin server role. Note
that this login is not actually able to login, it's just a connection
between the certificate and the permission.

There should be no need for making things trustworthy here.

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

Trapulo - 12 Mar 2008 17:22 GMT
> Hi Ola,
> Thanks for your response.
> Originally I just noticed that Trapulo said he wanted to kill processes on
> that DB, so I did not think of killing connections.

I'm sorry: I said processes because SQL calls them "process", but in fact I
was thinking about connections.

> Anyway I would like to add more comments regarding both killing a process
> and a connection. For killing a process, I just found that kill.exe is not
[quoted text clipped - 58 lines]
> rights.
> =========================================================
Charles Wang[MSFT] - 13 Mar 2008 13:05 GMT
Hi Trapulo,
It does not matter. Based on my discussions with Ola, we can conclude that
to kill a connection on your database with a limited login account, you
need to:
1. Use EXECUTE AS clause to impersonate a login account who has enough
permissions to kill a session;
2. Grant EXECUTE permission to the user account who is corresponding to
your limited login account to execute your stored procedure;
3. Grant IMPERSONATE on your login account with the sysadmin and
processadmin server roles to your limited login account.

Please try it to see if it helps at your side. If you have any other
questions or concerns, please feel free to let me know. Have a nice day!

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@microsoft.com.
=========================================================
Signature

This posting is provided "AS IS" with no warranties, and confers no rights.

=========================================================
 
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.