Und: Du mußt es aktivieren xp_cmdshell Server configuration option - SQL Server
und hier gibts auch noch Hilfe xp_cmdshell Error code 1385
und hier gibts auch noch Hilfe xp_cmdshell Error code 1385
Aus stored procedure in Datei auf dem Dateisystem schreiben
- Ersteller ukulele
- Erstellt am
Werbung:
ukulele
Datenbank-Guru
- Beiträge
- 5.140
sp_configure habe ich natürlich gemacht.
Das mit dem Batch Job Login sieht gut aus das werde ich mir in Zukunft noch angucken. Ich habe einen anderen Weg gefunden und werde die Datei jetzt lokal auf der SQL VM ablegen (über BCP queryout). Da berechtige ich einfach den Benutzer unter dem der DB Dienst läuft:
Auf jeden Fall vielen Dank für die Hilfe deiner Seits.
Das mit dem Batch Job Login sieht gut aus das werde ich mir in Zukunft noch angucken. Ich habe einen anderen Weg gefunden und werde die Datei jetzt lokal auf der SQL VM ablegen (über BCP queryout). Da berechtige ich einfach den Benutzer unter dem der DB Dienst läuft:
SQL:
EXEC master..xp_cmdshell 'whoami'Das hat für mich Vor- und Nachteile. Ich hoffe aber das dann jeder, der am Server angemeldet ist, die SP aufrufen kann und sie tut was sie soll.
Auf jeden Fall vielen Dank für die Hilfe deiner Seits.
dabadepdu
Datenbank-Guru
- Beiträge
- 1.701
Verstehe ich ehrlich gesagt nicht- aber ich sitze ja auch nicht davor. 
- Der SQL Service müsste Dateizugriffsrechte bekommen (immer der gleiche)
- Der App Owner in SQL müsste damit eine Schreiblese SP durchführen können
- Die Zugriffsrechte darauf müssten an irgendeine Gruppe oder spezifische User gegranted werden (Owner basiert, nicht invoker)
Was ich an dem ganzen Vorgang seltsam finde, dass -vermutlich zum Schutz- das Ganze so intransparent ist, dass aus purer Verzweifelung am Ende ein "alle dürfen" draus wird, weil es sonst zu kompliziert ist bzw. nicht zu funktionieren scheint.
- Der SQL Service müsste Dateizugriffsrechte bekommen (immer der gleiche)
- Der App Owner in SQL müsste damit eine Schreiblese SP durchführen können
- Die Zugriffsrechte darauf müssten an irgendeine Gruppe oder spezifische User gegranted werden (Owner basiert, nicht invoker)
Was ich an dem ganzen Vorgang seltsam finde, dass -vermutlich zum Schutz- das Ganze so intransparent ist, dass aus purer Verzweifelung am Ende ein "alle dürfen" draus wird, weil es sonst zu kompliziert ist bzw. nicht zu funktionieren scheint.
akretschmer
Datenbank-Guru
- Beiträge
- 10.321
... man sowas will.
- Zugriff auf das Filesystem des Servers? globales Sicherheitsproblem
- Zugriff auf das Filesystem des Clients? lokales Sicherheitssystem, dazu kann ja das Filesystem eines jeden Clients anders aussehen
- massiv unportabel
nach all der Diskussion gefällt mir eigentlich, daß sowas mit PG gar nicht (so einfach) möglich wäre, und in allen Dokus auch gesagt wird, daß man sowas nicht machen sollte.
Okay, ich bin wieder raus ...
Und ich frag mich warum jemand, der von SQL Server keine Ahnung trotzdem seinen Senf dazu gibt. 1. Isses net. Schließlich machste das aus dem SQL Server AUF dem Server. 2. Kein Mensch hat was von Clients geschrieben 3. Warum sollte es portabel sein??? Und komisch isses, daß das nach der Doku von PG deutlich einfacher geht als in SQL Server. Schönes Sicherheitsloch
akretschmer
Datenbank-Guru
- Beiträge
- 10.321
jein, es geht für Superuser, sonst nicht.
dabadepdu
Datenbank-Guru
- Beiträge
- 1.701
Tja, so einfach ist es ja wohl mit MSSQL auch nicht.
Serverseitige DV finde ich erstmal aus Ressourcengründen ziemlich ok. Das sollte auch im Fall "Daten einlesen" weniger ein Sicherheitsproblem sein.
Beim Schreiben (Datenexport) wird es natürlich kritischer und beim Schreiben von "Executables" noch mehr.
Am Ende sehe ich bei den PC der Mitarbeiter aber eine deutlich größere Angriffsfläche als am DB Server.
ukulele
Datenbank-Guru
- Beiträge
- 5.140
Ich wollte mit PG (ich glaube Version 9.x) auch mal Dateien lesen. Das wäre wohl gegangen aber nur aus einem Verzeichnis des DB-Servers. Das hätte beudeutet ich hätte etwa 8 Mio Dateien in dieses Verzeichnis schaufeln müssen - fand ich nicht so reizvoll und hab es bei MSSQL belassen.
Grundsätzlich sehe ich aber schon sinnvolle Verwendungszwecke. Meine Fähigkeiten beschränken sich stark auf SQL. Ich möchte nicht auf eine Applikation angewiesen sein die mir Rohdaten importiert, auch wenn das eventuell sicherer wäre. Am Ende mache ich das auf Servern auf denen kein User rum werkelt.
In diesem Projekt will ich eigentlich auch nur lesen. Allerdings werden die Daten zuvor von einem anderen, propritären und völlig veralteten Komandozeilentool exportiert. Ich möchte aber nicht regelmäßig alle Daten exportieren (ca. 180GB DB) sondern nach Bedarf. Das bedeutet ich muss eine Liste auslesen und abhängig von der Liste weitere Listen und abhängig davon dann Datenbestände. Den Aufruf für den Export über das Tool kann ich in SQL zusammen setzen weil SQL weiß was es schon hat und was es braucht. Jetzt habe ich den Aufruf als Batch exportiert.
Grundsätzlich sehe ich aber schon sinnvolle Verwendungszwecke. Meine Fähigkeiten beschränken sich stark auf SQL. Ich möchte nicht auf eine Applikation angewiesen sein die mir Rohdaten importiert, auch wenn das eventuell sicherer wäre. Am Ende mache ich das auf Servern auf denen kein User rum werkelt.
In diesem Projekt will ich eigentlich auch nur lesen. Allerdings werden die Daten zuvor von einem anderen, propritären und völlig veralteten Komandozeilentool exportiert. Ich möchte aber nicht regelmäßig alle Daten exportieren (ca. 180GB DB) sondern nach Bedarf. Das bedeutet ich muss eine Liste auslesen und abhängig von der Liste weitere Listen und abhängig davon dann Datenbestände. Den Aufruf für den Export über das Tool kann ich in SQL zusammen setzen weil SQL weiß was es schon hat und was es braucht. Jetzt habe ich den Aufruf als Batch exportiert.
Werbung: