Verwenden von EXECUTE AS in Modulen

EXECUTE AS kann zum Definieren des Ausführungskontexts der folgenden benutzerdefinierten Module verwendet werden: Funktionen, Prozeduren, Warteschlangen und Trigger. Der Ausführungskontext kann z. B. vom Aufrufer des Moduls zum Eigentümer des Moduls oder zu einem angegebenen Benutzer gewechselt werden. In früheren Versionen von SQL Server wurden diese Module immer im Kontext des Aufrufers des Moduls ausgeführt.

Durch das Angeben des Kontexts, in dem das Modul ausgeführt wird, können Sie steuern, welches Benutzerkonto von Database Engine (Datenbankmodul) verwendet wird, um Berechtigungen für beliebige Objekte, auf die durch das Modul verwiesen wird, zu überprüfen. Dies gewährleistet zusätzliche Flexibilität und Steuerung bei der Verwaltung von Berechtigungen für die gesamte Objektkette, die zwischen benutzerdefinierten Modulen und den Objekten, auf die durch diese Module verwiesen wird, vorhanden ist. Benutzer des Moduls benötigen nur Berechtigungen zum Ausführen des Moduls selbst; explizite Berechtigungen für die Objekte, auf die verwiesen wird, sind nicht erforderlich. Nur der Benutzer, als der das Modul ausgeführt wird, benötigt Berechtigungen für die Objekte, auf die das Modul zugreift.

EXECUTE AS CALLER

EXECUTE AS CALLER gibt an, dass die Anweisungen im Modul im Kontext des Aufrufers des Moduls ausgeführt werden.

Verwenden Sie EXECUTE AS CALLER für die folgenden Szenarien:

  • Sie möchten, dass die Anweisungen im Modul als der aufrufende Benutzer ausgeführt werden.

  • Sie wünschen Basisberechtigungsüberprüfungen für die Anweisungen im Modul für den aufrufenden Benutzer und verwenden ausschließlich Besitzverkettung zum Umgehen der Berechtigungsüberpüfungen der zugrunde liegenden Objekte. Denken Sie daran, dass Besitzverkettung nur für DML-Anweisungen gilt. Weitere Informationen zur Besitzverkettung finden Sie unter Besitzketten.

  • Ihre Anwendung verlangt nicht das Ausblenden der Objekte, auf die verwiesen wird, für den Benutzer, oder Sie verweisen nur auf Objekte des gleichen Besitzers und können aus diesem Grund mithilfe von Besitzverkettung das Ausblenden des Schemas bereitstellen.

  • Sie möchten das Verhalten von SQL Server 2000 beibehalten.

EXECUTE AS CALLER-Szenario

Mary erstellt eine gespeicherte Prozedur, die auf eine Tabelle verweist, deren Besitzer nicht Mary ist, für die sie jedoch über die SELECT-Berechtigung verfügt. Sie gibt EXECUTE AS CALLER in der CREATE PROCEDURE-Anweisung an, wie im folgenden Beispiel gezeigt:

CREATE PROCEDURE AccessTable
WITH EXECUTE AS CALLER
AS SELECT * FROM dbo.SomeTable;

Mary erteilt dann Scott EXECUTE-Berechtigungen für die gespeicherte Prozedur. Wenn Scott die gespeicherte Prozedur ausführt, überprüft Database Engine (Datenbankmodul), ob er (der Aufrufer) die Berechtigung zum Ausführen der gespeicherten Prozedur besitzt. Scott besitzt die EXECUTE-Berechtigung, aber da Mary nicht der Besitzer der Tabelle ist, auf die verwiesen wird, überprüft Database Engine (Datenbankmodul), ob Scott über Berechtigungen für die Tabelle verfügt. Wenn Scott keine Berechtigungen besitzt, schlägt die Anweisung der gespeicherten Prozedur fehl.

EXECUTE AS user_name

EXECUTE AS user_name gibt an, dass die Anweisungen im Modul im Kontext des in user_name angegebenen Benutzers ausgeführt werden.

Verwenden Sie EXECUTE AS user_name für die folgenden Szenarien:

  • Sie möchten, dass die Anweisungen im Modul im Kontext eines angegebenen Benutzers ausgeführt werden.

  • Sie können keine Besitzverkettung verwenden (das Modul greift z. B. auf Objekte mit verschiedenen Besitzern zu), um das zugrunde liegende Schema auszublenden, und Sie möchten das Erteilen von Berechtigungen für diese Objekte vermeiden, auf die verwiesen wird.

  • Sie möchten einen benutzerdefinierten Berechtigungssatz erstellen. Sie möchten z. B. Berechtigungen für DDL-Vorgänge bereitstellen, für die bestimmte Berechtigungen normalerweise nicht erteilt werden können. Weitere Informationen finden Sie unter Verwenden von EXECUTE AS zum Erstellen benutzerdefinierter Berechtigungssätze.

    HinweisHinweis

    Ein Benutzer, der als Ausführungskontext eines Moduls angegeben wird, kann erst gelöscht werden, nachdem der Ausführungskontext des betreffenden Moduls geändert wurde.

EXECUTE AS user_name-Szenario

Mary erstellt eine gespeicherte Prozedur, die auf eine Tabelle verweist, deren Besitzer nicht Mary ist, für die sie jedoch über die SELECT-Berechtigung verfügt. Sie gibt EXECUTE AS 'Mary' in der CREATE PROCEDURE-Anweisung an, wie im folgenden Beispiel gezeigt:

CREATE PROCEDURE AccessMyTable
WITH EXECUTE AS 'Mary'
AS SELECT * FROM dbo.MyTable;

Mary erteilt dann Scott EXECUTE-Berechtigungen für die gespeicherte Prozedur. Wenn Scott die gespeicherte Prozedur ausführt, überprüft Database Engine (Datenbankmodul), ob er die Berechtigung zum Ausführen der gespeicherten Prozedur besitzt; die Berechtigungen für die Tabelle, auf die verwiesen wird, werden jedoch für Mary überprüft. In diesem Szenario kann Scott über die Prozedur auf die Daten zugreifen, obwohl er nicht direkt über SELECT-Berechtigungen für die Tabelle verfügt, da Mary, in deren Kontext die Prozedur ausgeführt wird, Berechtigungen für den Zugriff auf die Daten in der Tabelle besitzt.

EXECUTE AS SELF

EXECUTE AS SELF entspricht EXECUTE AS user_name, wobei der angegebene Benutzer die Person ist, die das Modul erstellt oder ändert.

Verwenden Sie EXECUTE AS SELF für die folgenden Szenarien:

  • Sie wünschen eine Kurzform zum Angeben Ihrer eigenen Person als der Benutzer, unter dessen Kontext die Anweisungen des Moduls ausgeführt werden, das Sie erstellen oder ändern.

  • Sie verwenden eine Anwendung, die Module für Benutzer erstellt, die diese aufrufen, und Sie möchten, dass diese Module mithilfe dieser Benutzer als Ausführungskontext erstellt werden. In diesem Szenario wissen Sie zur Entwurfszeit nicht, wie der Name des aufrufenden Benutzers lautet.

EXECUTE AS OWNER

EXECUTE AS OWNER gibt an, dass die Anweisungen im Modul im Kontext des Aufrufers des aktuellen Besitzers des Moduls ausgeführt werden. Wenn das Modul keinen angegebenen Besitzer aufweist, wird der Besitzer des Schemas des Moduls verwendet.

Verwenden Sie EXECUTE AS OWNER für das folgende Szenario:

  • Sie möchten den Besitzer des Moduls ändern können, ohne das Modul selbst ändern zu müssen. Dies bedeutet, das OWNER automatisch dem aktuellen Besitzer des Moduls zur Laufzeit zugeordnet wird.

OWNER ist der explizite Besitzer des Moduls oder, wenn kein expliziter Besitzer vorhanden ist, der Besitzer des Schemas des Moduls zum Zeitpunkt der Ausführung des Moduls. OWNER muss ein Singleton-Konto sein, keine Gruppe oder Rolle. Der Besitz des Moduls kann nicht in eine Gruppe oder Rolle geändert werden, wenn das Modul EXECUTE AS OWNER angibt und einen expliziten Besitzer aufweist. Der Besitz eines Schemas kann nicht in eine Gruppe oder Rolle geändert werden, wenn dieses ein Modul aufweist, das EXECUTE AS OWNER angibt, und die Module keinen expliziten Besitzer aufweisen.

EXECUTE AS OWNER-Szenario

Mary erstellt eine gespeicherte Prozedur, die auf eine Tabelle in ihrem Besitz verweist. Sie gibt EXECUTE AS OWNER in der CREATE PROCEDURE-Anweisung an, wie im folgenden Beispiel gezeigt:

CREATE PROCEDURE Mary.AccessMyTable
WITH EXECUTE AS OWNER
AS SELECT * FROM Mary.MyTable;

Mary erteilt dann Scott EXECUTE-Berechtigungen für die gespeicherte Prozedur. Wenn Scott die gespeicherte Prozedur ausführt, überprüft Database Engine (Datenbankmodul), ob er die Berechtigung zum Ausführen der gespeicherten Prozedur besitzt; die Berechtigungen für die Tabelle, auf die verwiesen wird, werden jedoch für Mary überprüft, weil sie der aktuelle Besitzer der Prozedur ist. Mary verlässt das Unternehmen und überträgt den Besitz der Prozedur und Tabelle an Tom. Wenn Scott die gespeicherte Prozedur nach der Änderung des Besitzers ausführt, kann er auch weiterhin über die Prozedur auf die Daten zugreifen, weil OWNER automatisch Tom zugeordnet wird.