it-swarm.com.de

Gespeicherte Prozedur und Berechtigungen - ist EXECUTE genug?

Ich habe eine SQL Server 2008-Datenbank, in der der Zugriff auf die zugrunde liegenden Tabellen über gespeicherte Prozeduren erfolgt. Einige gespeicherte Prozeduren SELECT Datensätze einfach aus den Tabellen, während andere UPDATE, INSERT und DELETE. 

Wenn eine gespeicherte Prozedur eine Tabelle AKTUALISIERT, benötigt der Benutzer, der die gespeicherte Prozedur ausführt, auch UPDATE-Berechtigungen für die betroffenen Tabellen oder ist die Tatsache, dass sie EXECUTE-Berechtigungen für die gespeicherte Prozedur besitzen, ausreichend? 

Grundsätzlich frage ich mich, ob es ausreichend ist, dem Benutzer EXECUTE-Berechtigungen für die gespeicherten Prozeduren zu geben, oder muss ich ihnen SELECT-, UPDATE-, DELETE- und INSERT-Berechtigungen für die Tabellen erteilen, damit die gespeicherten Prozeduren funktionieren. Vielen Dank.

[EDIT] In den meisten meiner gespeicherten Prozeduren scheint es, dass EXECUTE ausreicht. Ich fand jedoch, dass EXECUTE in gespeicherten Prozeduren, in denen "Execute sp_Executesql" verwendet wurde, nicht ausreicht. Die beteiligten Tabellen mussten über Berechtigungen für die Aktionen verfügen, die innerhalb von "sp_Executesql" ausgeführt werden.

34
webworm

Ausführungsberechtigungen für die gespeicherte Prozedur sind ausreichend.

CREATE TABLE dbo.Temp(n int)

GO
DENY INSERT ON dbo.Temp TO <your role>
GO
CREATE PROCEDURE dbo.SPTemp(@Int int)
AS

INSERT dbo.Temp
SELECT  @Int 

GO

GRANT EXEC ON dbo.SPTemp TO <your role>

GO

Dann hat der (Nicht-db_owner) Benutzer die folgenden Rechte:

EXEC dbo.SPTemp 10
GO

INSERT dbo.Temp --INSERT permission was denied on the object 'Temp'
SELECT  10

Wenn jedoch dynamisches SQL in dbo.SPTemp vorhanden ist, das versucht, in dbo.Temp einzufügen, schlägt dies fehl. In diesem Fall muss eine direkte Erlaubnis für den Tisch erteilt werden.

12
Noel Abrahams

Berechtigungen für Tabellen werden nicht geprüft (einschließlich DENY), wenn Tabellen und Proc denselben Besitzer haben. Sie können sich auch in verschiedenen Schemata befinden, solange die Schemas denselben Besitzer haben.

Siehe Ownership Chaining in MSDN

Bearbeiten Sie einen Kommentar aus einer gelöschten Antwort.

Der Kontext ist immer das aktuelle Login, sofern nicht EXECUTE AS verwendet wurde: Nur DML-Berechtigungen für referenzierte Objekte werden nicht geprüft. Versuchen Sie OBJECT_ID (referenzierteTabelle) in einer gespeicherten Prozedur, in der der referenzierten Tabelle keine Rechte zugewiesen sind. Es gibt NULL. Wenn sie vom Eigentümer der gespeicherten Prozedur ausgeführt wird, würde dies einen Wert ergeben, da Owener über die referenzierte Tabelle verfügt

24
gbn

Vielleicht kannst du verwenden 

"mit als Eigentümer ausführen"

wenn Sie die gespeicherte Prozedur erstellen, wie folgt:

create procedure XXX
with execute as owner
as
begin
...
end
go

Dann müssen Sie dem Benutzer nur die Berechtigung EXECUTE für die gespeicherte Prozedur XXX erteilen.

3
yuan liu

Die Ausführungsberechtigung für eine gespeicherte Prozedur, die ein Einfügen, Aktualisieren oder Löschen ausführt, ist ausreichend. Sie müssen diese Berechtigungen nicht auf Tabellenebene erteilen. In der Tat würde ich diesen Ansatz entmutigen. Die Verwendung einer gespeicherten Prozedur gibt Ihnen mehr Kontrolle darüber, wie die Änderung auftritt. Beispielsweise möchten Sie möglicherweise einige Überprüfungen durchführen, bevor Sie die Aktualisierung zulassen. Die Verwendung einer gespeicherten Prozedur kann auch dazu beitragen, schwere Unfälle zu vermeiden - beispielsweise das Löschen aller Zeilen in der Tabelle, weil jemand die WHERE-Klausel vergessen hat!

2
Bryan Cooper

DANKE SO VIEL! Ich hatte ein ähnliches Problem. Dies führte mich zur Antwort.

Ich habe versucht, eine Tabelle in einer gespeicherten Prozedur zu tun, die andere gespeicherte Prozeduren aufrief, die in IF-Anweisungen verschachtelt waren.

Mein Fehler war 

Der Server-Principal "Domäne\Meine_ID" kann im aktuellen Sicherheitskontext nicht auf die Datenbank "2nd_DB" zugreifen.

Ich hatte der aufrufenden gespeicherten Prozedur Rechte zum Abschneiden gegeben (EXECUTE AS SELF), was dann ein Problem verursachte, da SELF keine Rechte für die 2. DB hatte. Unsere Lösung bestand darin, das gekürzte zu einem anderen SP zu verschieben, einschließlich des EXECUTE AS SELF. Wir rufen jetzt den abgeschnittenen SP auf, führen unsere Datenverarbeitung durch, treffen eine logische Bestimmung und rufen den entsprechenden 3. SP auf.

1
ARLibertarian