Cela a été désactivé par défaut à partir de SQL Server 2005, lorsqu'ils ont introduit le Outil de configuration de la surface
, dans le but de rendre SQL Server plus sécurisé par défaut. Cet outil a depuis été retiré, mais vous pouvez toujours contrôler le comportement à l'aide de sp_configure
. Un exemple est affiché sur 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
(J'ai aussi blogué à ce sujet il y a de nombreuses années .)
La raison en est qu'il s'agit d'une faille de sécurité potentielle. Si vous autorisez SQL Server à exécuter xp_cmdshell
, alors ils peuvent théoriquement envoyer tout commande du système d'exploitation là-bas, en contournant toutes les sécurités que vous pensiez avoir. Cela est particulièrement problématique lorsque le compte de service SQL Server et/ou le compte proxy ont été élevés au niveau sysadmin ou à d'autres niveaux, car c'est plus facile que de définir explicitement uniquement les choses exactes qu'ils doivent pouvoir faire.
Plutôt que de l'activer et de le désactiver pour prendre en charge l'interaction de la ligne de commande, un moyen courant d'exposer les fonctionnalités du système d'exploitation tout en conservant un certain contrôle sur la sécurité consiste à implémenter la fonctionnalité au niveau du système d'exploitation dont vous avez besoin à l'aide de SQL-CLR. Voici un bon point de départ pour accéder au système de fichiers avec CLR (cependant si vous cherchez autour vous trouverez des approches beaucoup plus modernes et exhaustives).
