EXECUTE permission was denied

Ein User erstellt eine Prozedur und versucht sie anschließend auszuführen. Er bekommt aber die Meldung: Nachricht 229, Stufe 14, Status 5, Prozedur usp_MeineProzedur, Zeile 1 [Batchstartzeile 0] The EXECUTE permission was denied on the object 'usp_MeineProzedur', database 'MeineDB', schema 'dbo'.
Warum?

Das Szenario

Der User ist ein Entwickler und ist in der Datenbank nicht in der Rolle db_owner, sondern in diesen drei Rollen:

  • db_datareader (Damit er die Daten lesen kann)
  • db_datawriter (Damit er die Daten ändern kann)
  • db_ddladmin (Damit er die DDL-Strukturen ändern kann)

Die Prozedur "dbo.usp_MeineProzedur" wurde von dem User erstellt.

Die Lösung

Das entscheidende Recht, was in der Auflistung oben noch fehlt, ist die Berechtigung die Prozedur auszuführen. Hier gibt es zwei Wege, die aber beide von einem Mitglied der db_owner-Rolle eingerichtet werden müssen.

1. Execute Recht explizit

Man vergibt an den User (oder besser an die gemeinsame Rolle für alle Entwickler) das Recht die Prozedur auszuführen.

GRANT EXECUTE ON dbo.usp_MeineProzedur to [Entwickler-Rolle];

2. Execute Recht für alle Prozeduren im Schema

Wenn man nicht für jede einzelne Prozedur das Recht vergeben möchte, kann man auch den Entwicklern das Execute-Recht für das gesamte Schema geben, oder besser der gemeinsamen Rolle für alle Entwickler.

GRANT EXECUTE ON SCHEMA::dbo to [Entwickler-Rolle];

Was man nicht vergessen sollte

Natürlich muss auch für den produktiven Bereich ein klares Berechtigungskonzept vorliegen. Dort sollte es also eine Rolle für die Anwender geben, die gezielt die benötigten Berechtigungen bekommt. Die Rolle der Entwickler kann beibehalten werden, wenn sichergestellt ist, dass dort dauerhaft keine User zugeordnet sind. Zur Fehlerbehebung kann man dann temporär noch mal einen User dort aufnehmen.

Weiterhin sollte man möglichst eine Trennung der Objekte in verschiedene Schemata vorsehen, da hierdurch die Berechtigungsvergabe transparenter wird.