SQL Server Forum / General / Security / March 2008
user permissions
|
|
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.
=========================================================
|
|
|