Това е деактивирано веднага след SQL Server 2005, когато те въведоха Инструмент за конфигуриране на повърхностна площ
, в опит да направи SQL Server по-сигурен по подразбиране. Този инструмент оттогава е оттеглен, но все още можете да контролирате поведението с помощта на sp_configure
. Пример е показан в 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
(Аз също писах в блог за това преди много години .)
Причината е, че това е потенциална дупка в сигурността. Ако позволите на SQL Server да изпълни xp_cmdshell
, тогава те теоретично могат да изпратят всички командване на операционната система там, заобикаляйки всякаква сигурност, която сте смятали, че имате. Това е особено проблематично, когато акаунтът за услугата на SQL Server и/или акаунтът за прокси е повишен до sysadmin или други нива, защото това е по-лесно, отколкото изрично да се дефинират само точните неща, които те трябва да могат да правят.
Вместо да го активирате и деактивирате, за да поддържате взаимодействие с командния ред, популярен начин за излагане на функционалност на операционната система, като същевременно имате известен контрол върху сигурността, е да внедрите функционалността на ниво операционна система, от която се нуждаете, с помощта на SQL-CLR. Ето добра отправна точка за достъп до файлова система с CLR (но ако търсите наоколо, ще намерите много по-модерни и изчерпателни подходи).