web-dev-qa-db-fra.com

L'accès au chemin «c: \ certains \ chemin» est refusé pour MSSQL CLR

Je pense que c'est un problème d'autorisations, mais j'ai du mal à le localiser.

J'ai un groupe de CLR sur un serveur (SQL Server 2016) et ils fonctionnent comme ils le devraient. Tous sont marqués UNSAFE et ils font différents types d'E/S de fichiers (lecture, écriture, copie, déplacement, renommage, etc.). Je peux les exécuter via SSMS ou à partir d'un travail avec la même facilité.

Je dois les installer sur un autre serveur (également SQL Server 2016). En utilisant le projet Visual Studio d'origine, je les ai déployés sur le nouveau serveur. Ils apparaissent dans SSMS. Cette partie semble bien.

Lorsque j'essaye d'en exécuter un à partir de SSMS, j'obtiens l'erreur suivante: "L'accès au chemin" quel que soit le chemin que j'ai passé "est refusé."

Je suis connecté à SSMS sous mon identifiant Windows. J'ai des autorisations sur la base de données, je suis dbo. Je suis administrateur sur le serveur. J'ai des autorisations dans le système de fichiers.

Que pouvais-je manquer de plus?

sql-serversql-server-2016permissionssql-clrfiles
8
WillG

J'ai des autorisations sur la base de données, je suis dbo. Je suis administrateur sur le serveur. J'ai des autorisations dans le système de fichiers.

Rien de tout cela n'a d'importance, généralement. À moins que vous (ou celui qui a codé les méthodes SQLCLR) n'implémentiez l'emprunt d'identité, le contexte de sécurité utilisé pour les opérations externes est celui du compte de service exécutant SQL Server (similaire à xp_cmdshell comportement). C'est ce compte qui a besoin d'une autorisation d'accès aux chemins d'accès auxquels vous essayez d'accéder.

Par souci d'exhaustivité concernant les autorisations d'accès aux fichiers:

  1. Pour un accès local (sur la boîte), c'est aussi simple que
    1. le compte de service (comportement par défaut) pour le service du moteur de base de données (c'est-à-dire MSSQLSERVER ou MSSQL $ InstanceName) nécessitant une autorisation, ou
    2. si l'emprunt d'identité a été implémenté dans le code
      1. et a la connexion exécutant le code est une connexion Windows, pas une connexion SQL Server, alors c'est que Compte Windows nécessitant une autorisation
      2. mais une connexion SQL Server est utilisée, l'accès externe est toujours effectué en tant que compte de service du moteur de base de données
  2. Pour l'accès à distance (lecteur partagé), il peut être nécessaire de configurer une délégation contrainte (via Active Directory, y compris les SPN). Bon problème de double-hop Kerberos. Dans ce cas, vous verriez une différence entre la connexion à SQL Server à partir d'un autre ordinateur, autre que le serveur sur lequel il s'exécute, et la connexion directe au serveur exécutant SQL Server, puis la connexion à l'instance SQL Server locale.

Gardez à l'esprit que les "DENY" ont priorité sur les "GRANT" (tout comme avec les autorisations SQL Server).

Afin de déterminer si le compte utilisé pour l'accès externe a réellement l'autorisation nécessaire pour le (s) dossier (s) et/ou fichier (s):

  1. Accédez aux "Propriétés" du chemin en question (le fichier ou dossier spécifique signalant l'erreur)
  2. Allez dans l'onglet "Sécurité"
  3. Cliquez sur le bouton "Avancé"
  4. Accédez à l'onglet "Accès effectif"
  5. Cliquez sur le lien "sélectionner un utilisateur"
  6. Entrez le nom complet du compte (par exemple NT Service\MSSQLSERVER)
  7. Cliquez sur le bouton "OK"
  8. Cliquez sur le bouton "Afficher l'accès effectif"
  9. Ce compte a-t-il accès à cette ressource?

Y a-t-il des autorisations DENY n'importe où dans le chemin d'accès auquel vous essayez d'accéder?

AUSSI Si tout le code ne concerne que le système de fichiers, alors vous n'avez probablement pas besoin que l'assembly soit marqué comme UNSAFE et il devrait plutôt être EXTERNAL_ACCESS. Pas trop d'opérations de système de fichiers devraient nécessiter UNSAFE. L'un d'eux obtient une liste de lecteurs fixes, mais ne sait pas quoi d'autre.

12
Solomon Rutzky

Assurez-vous que le compte de service exécutant SQL Server a accès à ces chemins.

Ce sera le compte qui interagit réellement avec les fichiers sur le disque.

2
BradC

Au cas où vous l'auriez fait de toutes les manières mentionnées ci-dessus, mais cela n'a pas fonctionné. D'après mon expérience jusqu'à présent, vous pouvez essayer d'ouvrir SSMS en tant que Administrateur.

0
Dat Nguyen