it-swarm.com.de

Der Zugriff auf den Pfad 'c: \ some \ path' wird für MSSQL CLR verweigert

Ich denke, dies ist ein Berechtigungsproblem, aber ich habe Probleme, es zu finden.

Ich habe eine Gruppe von CLRs auf einem Server (SQL Server 2016) und sie funktionieren wie sie sollten. Alle sind als UNSICHER gekennzeichnet und führen verschiedene Arten von Datei-E/A aus (Lesen, Schreiben, Kopieren, Verschieben, Umbenennen usw.). Ich kann sie über SSMS oder von einem Job aus genauso einfach ausführen.

Ich muss sie auf einem anderen Server installieren (auch SQL Server 2016). Mit dem ursprünglichen Visual Studio-Projekt habe ich sie auf dem neuen Server bereitgestellt. Sie werden in SSMS angezeigt. Dieser Teil sieht gut aus.

Wenn ich über SSMS versuche, einen auszuführen, wird die folgende Fehlermeldung angezeigt: "Der Zugriff auf den Pfad" Der Pfad, den ich übergeben habe "wird verweigert."

Ich bin unter meinem Windows-Login bei SSMS angemeldet. Ich habe Berechtigungen für die Datenbank, ich bin dbo. Ich bin ein Administrator auf dem Server. Ich habe Berechtigungen im Dateisystem.

Was könnte ich sonst noch vermissen?

8
WillG

Ich habe Berechtigungen für die Datenbank, ich bin dbo. Ich bin ein Administrator auf dem Server. Ich habe Berechtigungen im Dateisystem.

Nichts davon ist normalerweise von Bedeutung. Sofern Sie (oder wer auch immer die SQLCLR-Methoden codiert hat) den Identitätswechsel nicht implementiert haben, wird für externe Vorgänge der Sicherheitskontext verwendet, der für das Dienstkonto verwendet wird, auf dem SQL Server ausgeführt wird (ähnlich dem Verhalten von xp_cmdshell). Dieses Konto benötigt die Berechtigung für die Pfade, auf die Sie zugreifen möchten.

Der Vollständigkeit halber in Bezug auf Dateizugriffsberechtigungen:

  1. Für den lokalen Zugriff (auf der Box) ist dies so einfach wie entweder
    1. das Dienstkonto (Standardverhalten) für den Datenbankmoduldienst (d. h. MSSQLSERVER oder MSSQL $ InstanceName), für den eine Berechtigung erforderlich ist, oder
    2. wenn der Identitätswechsel im Code implementiert wurde
      1. und a Das Login, das den Code ausführt, ist ein Windows-Login, kein SQL Server-Login, dann ist es das Windows-Konto, das eine Berechtigung benötigt
      2. Wenn jedoch eine SQL Server-Anmeldung verwendet wird, erfolgt der externe Zugriff weiterhin als Database Engine-Dienstkonto
  2. Für den Remotezugriff (freigegebenes Laufwerk) muss möglicherweise eine eingeschränkte Delegierung eingerichtet werden (über Active Directory; einschließlich SPNs). Gute alte Kerberos Double-Hop-Ausgabe. In diesem Fall sehen Sie einen Unterschied zwischen der Anmeldung bei SQL Server von einem anderen Computer als dem Server, auf dem es ausgeführt wird, und der direkten Anmeldung bei dem Server, auf dem SQL Server ausgeführt wird, und der anschließenden Verbindung mit der lokalen SQL Server-Instanz.

Beachten Sie, dass "DENY" Vorrang vor "GRANT" hat (genau wie bei SQL Server-Berechtigungen).

Um festzustellen, ob das für den externen Zugriff verwendete Konto tatsächlich über die erforderliche Berechtigung für die Ordner und/oder Dateien verfügt:

  1. Gehen Sie zu den "Eigenschaften" des betreffenden Pfads (die spezifische Datei oder der Ordner, in dem der Fehler gemeldet wird).
  2. Gehen Sie zur Registerkarte "Sicherheit"
  3. Klicken Sie auf die Schaltfläche "Erweitert"
  4. Gehen Sie zur Registerkarte "Effektiver Zugriff"
  5. Klicken Sie auf den Link "Benutzer auswählen"
  6. Geben Sie den vollständigen Kontonamen ein (z. B. NT Service\MSSQLSERVER).
  7. Klicken Sie auf die Schaltfläche "OK"
  8. Klicken Sie auf die Schaltfläche "Effektiven Zugriff anzeigen"
  9. Hat dieses Konto Zugriff auf diese Ressource?

Gibt es irgendwo auf dem Pfad, auf den Sie zugreifen möchten, DENY-Berechtigungen?


ALSO Wenn der gesamte Code Dateisystemmaterial ist, muss die Assembly höchstwahrscheinlich nicht als UNSAFE und markiert sein es sollte stattdessen EXTERNAL_ACCESS sein. Nicht zu viele Dateisystemoperationen sollten UNSAFE erfordern. Eine davon ist das Abrufen einer Liste fester Festplatten, aber nicht sicher, was noch.

12
Solomon Rutzky

Stellen Sie sicher, dass das Dienstkonto, auf dem SQL Server ausgeführt wird, Zugriff auf diese Pfade hat.

Das wird das Konto sein, das tatsächlich mit den Dateien auf der Festplatte interagiert.

2
BradC

Für den Fall, dass Sie alle oben genannten Wege gegangen sind, aber es hat nicht funktioniert. Nach meiner bisherigen Erfahrung können Sie versuchen, SSMS als Administrator zu öffnen.

0
Dat Nguyen