• Article

Restrictions du modèle de programmation de l'intégration du CLR

Lorsque vous générez une procédure stockée managée ou autre objet de base de données managé, certains contrôles de code effectués par SQL Server doivent être pris en compte. SQL Server effectue des contrôles sur l'assembly de code managé lorsqu'il est inscrit pour la première fois dans la base de données, à l'aide de l'instruction CREATE ASSEMBLY, et également pendant l'exécution. Le code managé est également vérifié pendant l'exécution, car dans un assembly il peut y avoir des chemins d'accès de code qui peuvent ne jamais être atteints pendant l'exécution. Cela fournit la souplesse nécessaire pour inscrire notamment des assemblys tiers, afin qu'un assembly ne soit pas bloqué là où il y a du code « potentiellement dangereux » conçu pour s'exécuter dans un environnement client, mais ne soit jamais exécuté dans le CLR hébergé. Les spécifications que le code managé doit satisfaire varient selon que l'assembly est inscrit comme SAFE, EXTERNAL_ACCESS ou UNSAFE, SAFE étant le plus strict, comme décrit plus bas.

En plus des restrictions imposées sur les assemblys de code managé, des autorisations de sécurité du code sont également accordées. Le Common Language Runtime (CLR) prend en charge un modèle de sécurité appelé sécurité d'accès du code pour le code managé. Dans ce modèle, les autorisations sont accordées aux assemblys selon l'identité du code. Les assemblys SAFE, EXTERNAL_ACCESS et UNSAFE ont des autorisations de sécurité d'accès du code différentes. Pour plus d'informations, consultez Sécurité d'accès du code de l'intégration du CLR.

Contrôles CREATE ASSEMBLY

Lorsque l'instruction CREATE ASSEMBLY est exécutée, les contrôles suivants sont effectués pour chaque niveau de sécurité. Si un contrôle échoue, CREATE ASSEMBLY échoue avec un message d'erreur.

Global (tout niveau de sécurité)

Tous les assemblys référencés doivent satisfaire un ou plusieurs des critères suivants :

  • L'assembly est déjà inscrit dans la base de données.

  • L'assembly est l'un des assemblys pris en charge. Pour plus d'informations, consultez Bibliothèques .NET Framework prises en charge.

  • Vous utilisez CREATE ASSEMBLY FROM<location>, et tous les assemblys référencés et leurs dépendances sont disponibles dans <location>.

  • Vous utilisez CREATE ASSEMBLY FROM<bytes …>, et toutes les références sont spécifiées via des octets séparés par des espaces.

EXTERNAL_ACCESS

Tous les assemblys EXTERNAL_ACCESS doivent répondre aux critères suivants :

  • Les champs statiques ne sont pas utilisés pour stocker des informations. Les champs statiques en lecture seule sont autorisés.

  • Le test PEVerify est réussi. L'outil PEVerify (peverify.exe), qui vérifie que le code MSIL et les métadonnées associées satisfont les spécifications de sécurité de type, est fourni dans le Kit de développement SDK .NET Framework.

  • La synchronisation, par exemple avec la classe SynchronizationAttribute, n'est pas utilisée.

  • Les méthodes finaliseurs ne sont pas utilisées.

Les attributs personnalisés suivants sont interdits dans les assemblys EXTERNAL_ACCESS :

  • System.ContextStaticAttribute

  • System.MTAThreadAttribute

  • System.Runtime.CompilerServices.MethodImplAttribute

  • System.Runtime.CompilerServices.CompilationRelaxationsAttribute

  • System.Runtime.Remoting.Contexts.ContextAttribute

  • System.Runtime.Remoting.Contexts.SynchronizationAttribute

  • System.Runtime.InteropServices.DllImportAttribute

  • System.Security.Permissions.CodeAccessSecurityAttribute

  • System.Security.SuppressUnmanagedCodeSecurityAttribute

  • System.Security.UnverifiableCodeAttribute

  • System.STAThreadAttribute

  • System.ThreadStaticAttribute

SAFE

  • Toutes les conditions d'assembly EXTERNAL_ACCESS sont vérifiées.

Contrôles d'exécution

Pendant l'exécution, les conditions suivantes sont vérifiées pour l'assembly de code. Si l'une de ces conditions est remplie, le code managé n'est pas autorisé à s'exécuter et une exception est levée.

UNSAFE

Le chargement d'un assembly, soit de manière explicite en appelant la méthode System.Reflection.Assembly.Load() à partir d'un tableau d'octets, soit de manière implicite au moyen de l'utilisation de l'espace de noms Reflection.Emit, n'est pas autorisé.

EXTERNAL_ACCESS

Toutes les conditions UNSAFE sont vérifiées.

Tous les types et méthodes annotés avec les valeurs d'attribut de protection de l'hôte suivantes dans la liste d'assemblys prise en charge sont interdits.

  • SelfAffectingProcessMgmt

  • SelfAffectingThreading

  • Synchronization

  • SharedState

  • ExternalProcessMgmt

  • ExternalThreading

  • SecurityInfrastructure

  • MayLeakOnAbort

  • UI

Pour plus d'informations sur les attributs de protection de l'hôte et pour obtenir une liste des types et membres interdits dans les assemblys pris en charge, consultez Attributs de protection de l'hôte et programmation de l'intégration CLR.

SAFE

Toutes les conditions EXTERNAL_ACCESS sont vérifiées.