none
Problem mit xp_cmdshell RRS feed

  • Frage

  • Die EXECUTE-Berechtigung wurde für das xp_cmdshell-Objekt, mssqlsystemresource-Datenbank, sys-Schema, verweigert. ODBC.QueryDef

    Dies ist die Fehlermeldung, die ich erhalte, wenn ich aus einer Access-DB heraus eine SToredProcedure aufrufe, die u.a. einen Aufruf einer xp_cmdshell enthält. Der Befehl soll eine Datei löschen, die zuvor in eine FielTable transferiert wurde.

    Ich habe schon einiges geggogelt und die Prozedur an sich freigegeben, dem Login für eine bestimmte Windows-gruppe die Berechtigung Execute erteilt und auch den Prox-Account auf genau diesen Benutzer eingestellt.

    Ich bin jetzt also soweit, daß ein Beispielaufruf "exec xp_cmshell 'dir *.exe' " durchläuft wenn  ich dies als Benutzer aus der berechtigten Gruppe tue. Das war zuvor (ohne Proxy-Account) nicht möglich.

    Trotzdem bekomme ich unverändert dieselbe Fehlermeldung. Es scheint ein generelles Problem mit der xp_ zu sein, nicht mit der zu löschenden Datei.

    Freitag, 16. Januar 2015 13:04

Antworten

  • Die sp tut folgendes: 

    - Einlesen der Quelldatei (rgendwo) in die Filetable

    - Erfassen der streamid für den zuegordneten AUftrag in anderer Tabelle

    - ANlegen eines Log-EIntrages

    - abschliessend Löschen der Quelldatei (da klemmt's !)

    Das Ganze als Transaktion um die Teilschritte rück-abwicklen zu können, falls was schiefgeht. Genau das passiert momentan wg. der Zugriffverletzung xp_cmdshell

    Bisher war im Code dem Aufurf der sp (bis dato ohne xp_cmdshell) ein 'Kill Quelldatei' nachgeschaltet - aber eben unabhängig vom Erfolg der sp.

    Ich habe noch einige andere Sps, bei denen xp_cmdshell erforderlich sein wird, insofern sollte die Geschichte laufen.

    Zunäcst einmal:

    CONTROL SERVER ist NICHT notwendig für die Verwendung von xp_cmdshell, wenn man den Proxy eingerichtet hat.

    Wäre es anders, bräuchte man auch keinen Proxy, denn CONTROL SERVER ist effektiv gesehen das gleiche wie sysadmin, nur etwas verschleiert. (CONTROL SERVER vs. sysadmin/sa: permissions, system procedures, DBCC, automatic schema creation and privilege escalation - caveats)


    Ansonsten wage ich mal zu behaupten, dass dass auch per SSIS geht. - Ohne die Berechtigungen derart aufzureißen.


    Zugegeben, da muss man etwas umdenken und sich ggfl mit dieser Technologie vertraut machen. Es liegt aber nahe, das es früher oder später noch weitere Ladeprozesse geben wird im Unternehmen, so dass das Know-How sicher noch oft zum Einsatz kommen würde.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    • Als Antwort markiert NicoNi Dienstag, 20. Januar 2015 22:36
    Samstag, 17. Januar 2015 14:39

Alle Antworten

  • Hallo Nico,

    schau mal bitte hier, da findest Du eine AFAIK vollständige Auflistung der notwendigen Einstellungen.

      http://sqlblog.com/blogs/tibor_karaszi/archive/2007/08/23/xp-cmdshell-and-permissions.aspx

      https://social.msdn.microsoft.com/Forums/sqlserver/en-US/3eecdf7c-ce4c-4b63-9a73-acff53d96089/how-to-give-execution-rights-to-a-stored-procedure-which-uses-xpcmdshell?forum=sqltools

    Ggfs. hast Du nur vergessen, den Proxyaccount oder die Umschaltung auf den Benutzer einzubauen.

    Wenn es nicht klappt, poste doch mal den gesamten Aufruf per T-SQL und oder lies dich mal in die verschiedenen Artikel hier ein:

      https://www.google.de/?gws_rd=ssl#q=EXECUTE+permission+denied+on+object+%27xp_cmdshell%27%2C+database+%27mssqlsystemresource%27%2C+schema+%27sys%27.

    Allerdings solltest Du dir das mit dem Aufruf von xp_cmdshell für alle User nochmal überlegen. Damit handelt man sich in der Regel mehr Probleme ein als man damit löst.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community




    Freitag, 16. Januar 2015 13:16
    Moderator
  • dem Login für eine bestimmte Windows-gruppe die Berechtigung Execute erteilt und auch den Prox-Account auf genau diesen Benutzer eingestellt.

    Hallo Nico,

    Execute Rechte reichen nicht aus, siehe xp_cmdshell (Transact-SQL) => Berechtigungen: "... muss die CONTROL SERVER-Berechtigung zur Ausführung verfügbar sein ..."

    Warum löscht Du die Datei nicht aus MS Access/VBA heraus?


    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    Freitag, 16. Januar 2015 13:41
  • Die sp tut folgendes: 

    - Einlesen der Quelldatei (rgendwo) in die Filetable

    - Erfassen der streamid für den zuegordneten AUftrag in anderer Tabelle

    - ANlegen eines Log-EIntrages

    - abschliessend Löschen der Quelldatei (da klemmt's !)

    Das Ganze als Transaktion um die Teilschritte rück-abwicklen zu können, falls was schiefgeht. Genau das passiert momentan wg. der Zugriffverletzung xp_cmdshell

    Bisher war im Code dem Aufurf der sp (bis dato ohne xp_cmdshell) ein 'Kill Quelldatei' nachgeschaltet - aber eben unabhängig vom Erfolg der sp.

    Ich habe noch einige andere Sps, bei denen xp_cmdshell erforderlich sein wird, insofern sollte die Geschichte laufen.

    Samstag, 17. Januar 2015 12:28
  • Hallo Nico,

    ich würde mich dennoch nach einer Alternative umschauen. Mit xp_cmdshell kannst Du so ziemlich alles machen. Angefangen von Dateimanipulation über Systemänderungen bis hin zum lahmlegen des Rechners. Das kann man zwar teilweise durch Sicherheitseinstellungen verhindern, für sinnvoll halte ich das aber nicht.

    Für Admins wäre das noch Ok. Aber ansonsten würde ich es nicht nutzen und daher auch nicht zur Verfügung stellen (wenn auch nur indirekt).

    Es gibt für fast alles alternative Wege, um sein Ziel zu erreichen. Das wird hier nicht anders sein. Um dir dabei aber helfen zu können, müsste man noch erheblich mehr Details kennen. Was wird von wo aus über welche Wege aufgerufen? Wie sieht die Verbindung zwischen Client und Server aus? Welche exakten Anforderungen gibt es hier? ...

    Falls Du das nicht willst, ist das aber ok. Wenn Du die o.g. Links und den Hinweis von Olaf berücksichtigst, sollte es auch so laufen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 17. Januar 2015 12:37
    Moderator
  • Okay, das Häkchen bei "Steuern" habe ich jetzt gesetzt (master->xp_cmdshell)

    Ich sehe gerade, daß ich 2x "Ausführen" bei den Berechtigungen habe. Außerdem eine weitere Ungereimtheit:

    Unter Benutzer oder Rollen ist die Windows-benutzergruppe aufgeführt, mit der ich auf den Server zugreife (natürlich mit meinem Benutzeraccount.

    DIes angeklickt sehe ich die expliziten Berechtigungen Ausführen und Steuern. Wähle ich aber dias Register Effektiv an, dann sehe ich dort eine Meldung:

    "Die Ausführung als Server-Prinzipal ist  nicht möglich, weil der Prinzipal (die Gruppe) nicht vorhanden ist, für diesen Prinzipal kein Identitätswechsel mäglich ist, oder sie nicht die erforderliche Berechtigung haben.

    Was heisst das denn ?

    Samstag, 17. Januar 2015 12:38
  • Die sp tut folgendes: 

    - Einlesen der Quelldatei (rgendwo) in die Filetable

    - Erfassen der streamid für den zuegordneten AUftrag in anderer Tabelle

    - ANlegen eines Log-EIntrages

    - abschliessend Löschen der Quelldatei (da klemmt's !)

    Das Ganze als Transaktion um die Teilschritte rück-abwicklen zu können, falls was schiefgeht. Genau das passiert momentan wg. der Zugriffverletzung xp_cmdshell

    Bisher war im Code dem Aufurf der sp (bis dato ohne xp_cmdshell) ein 'Kill Quelldatei' nachgeschaltet - aber eben unabhängig vom Erfolg der sp.

    Ich habe noch einige andere Sps, bei denen xp_cmdshell erforderlich sein wird, insofern sollte die Geschichte laufen.

    Zunäcst einmal:

    CONTROL SERVER ist NICHT notwendig für die Verwendung von xp_cmdshell, wenn man den Proxy eingerichtet hat.

    Wäre es anders, bräuchte man auch keinen Proxy, denn CONTROL SERVER ist effektiv gesehen das gleiche wie sysadmin, nur etwas verschleiert. (CONTROL SERVER vs. sysadmin/sa: permissions, system procedures, DBCC, automatic schema creation and privilege escalation - caveats)


    Ansonsten wage ich mal zu behaupten, dass dass auch per SSIS geht. - Ohne die Berechtigungen derart aufzureißen.


    Zugegeben, da muss man etwas umdenken und sich ggfl mit dieser Technologie vertraut machen. Es liegt aber nahe, das es früher oder später noch weitere Ladeprozesse geben wird im Unternehmen, so dass das Know-How sicher noch oft zum Einsatz kommen würde.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    • Als Antwort markiert NicoNi Dienstag, 20. Januar 2015 22:36
    Samstag, 17. Januar 2015 14:39
  • Gestern habe ich nach den Misserfolgen trotz Abarbeitens der Anleitung den SQL neu gestartet. Dann hat es möglicherweise geklappt. Ich muss aber nochmal systematisch probieren.
    Montag, 19. Januar 2015 09:43