Dies wurde ab SQL Server 2005 standardmäßig deaktiviert, als Oberflächenkonfigurationstool
, um SQL Server standardmäßig sicherer zu machen. Dieses Tool wurde inzwischen eingestellt, aber Sie können das Verhalten weiterhin mit sp_configure
. Ein Beispiel wird auf MSDN gezeigt
:
-- 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
(Ich habe darüber vor vielen Jahren auch gebloggt .)
Der Grund dafür ist, dass dies eine potenzielle Sicherheitslücke ist. Wenn Sie zulassen, dass SQL Server xp_cmdshell ausführt
, dann können sie theoretisch beliebige senden dort den Befehl des Betriebssystems und umgehen dabei alle Sicherheitsvorkehrungen, von denen Sie dachten, dass Sie sie hätten. Dies ist besonders problematisch, wenn das SQL Server-Dienstkonto und/oder das Proxy-Konto auf sysadmin oder andere Ebenen angehoben wurden, da dies einfacher ist, als explizit nur die genauen Dinge zu definieren, zu denen sie in der Lage sein sollten.
Anstatt es zu aktivieren und zu deaktivieren, um die Befehlszeileninteraktion zu unterstützen, besteht eine beliebte Möglichkeit, Betriebssystemfunktionen verfügbar zu machen und gleichzeitig eine gewisse Kontrolle über die Sicherheit zu haben, darin, die von Ihnen benötigte Funktionalität auf Betriebssystemebene mit SQL-CLR zu implementieren. Hier ist ein guter Ausgangspunkt für den Zugriff auf die Dateisystem mit CLR (Wenn Sie sich jedoch umsehen, werden Sie viel modernere und umfassendere Ansätze finden).
