Detta har inaktiverats direkt från och med SQL Server 2005, när de introducerade Surface Area Configuration Tool
, i ett försök att göra SQL Server säkrare som standard. Det verktyget har sedan dess tagits bort, men du kan fortfarande kontrollera beteendet med sp_configure
. Ett exempel visas på MSDN
:
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
GO
-- To update the currently configured value for advanced options.
RECONFIGURE
GO
-- To enable the feature.
EXEC sp_configure 'xp_cmdshell', 1
GO
-- To update the currently configured value for this feature.
RECONFIGURE
GO
(Jag bloggade också om detta för många år sedan .)
Anledningen är att detta är ett potentiellt säkerhetshål. Om du tillåter SQL Server att köra xp_cmdshell
, då kan de teoretiskt skicka vilken som helst operativsystemkommandot där, kringgå all säkerhet du trodde att du hade. Detta är särskilt problematiskt när SQL Server-tjänstkontot och/eller proxykontot har höjts till sysadmin eller andra nivåer eftersom det är enklare än att explicit bara definiera de exakta saker som de ska kunna göra.
Istället för att aktivera och inaktivera det för att stödja kommandoradsinteraktion, är ett populärt sätt att exponera operativsystemets funktionalitet samtidigt som du fortfarande har viss kontroll över säkerheten att implementera den funktionalitet på OS-nivå du behöver med SQL-CLR. Här är en bra utgångspunkt för att komma åt filsystem med CLR (men om du letar runt hittar du mycket mer moderna och uttömmande metoder).