Ausführberechtigung für gespeicherte Prozedur

K

kleinUNDhilflos

Benutzer
Beiträge
5
Hallo Zusammen,

ich habe einen User der in der Datenbankrolle: "db_datareader" ist.

Ein "SELECT" auf irgendeine Tabelle klappt auch ganz wunderbar. Jetzt möchte ich eine Prozedur ausführen, dazu habe ich als dbo einen Rechtsklick auf die Prozedur gemacht und bei Berechtigungen den User mit Ausführen -> Erteilen ein Häckchen gemacht.
Da ich in der Prozedur einen Benutzerdefinierten Tabellentyp verwende habe ich auch bei diesem dem User die Rechte "Definition anzeigen" und "Verweis" gegeben.

Wenn ich nun versuche mit dem User die Prozedur auszuführen erhalte ich:
"Meldung 229, Ebene 14, Status 5, Zeile 0
Die EXECUTE-Berechtigung wurde für das StaDa_Tabletype-Objekt, XXX-Datenbank, dbo-Schema, verweigert."

Was habe ich vergessen?

Vielen Dank


Gruß Uwe
 
Werbung:
Hi,

mit Rechts-Klick die Eigenschaften der Prozedur aufrufen.
unter Berechtigung > Benutzer oder Rollen den Benutzer (oder die entsprechend angelegte Rolle) hinzufügen
den hinzugefügten Eintrag markieren
unten ind der Liste mit den Berechtigungen die Auswahl "Ausführen" markieren und OK klicken - fertig

Dann sollte es funktionieren.

Viele Grüße,
Tommi
 
Das oben genannte Verfahren hat den Nachteil, dass nach Modifikation der Procedure, die ggf. ein Delete/Create enthält, die Berechtigung jedes mal neu erteilt werden muss. Ausserdem muss man das für jede SP (=stored procedure) und evtl. auch jeder UDF (userdefined function, nicht getestet) extra zugewiesen werden.

Soll das etwas globaler gelten ohne andererseits zu viele Rechte global zu aktivieren, also z.B. je (z.B. technischem) User für eine spezielle Projekt-Datenbank, funktioniert folgendes:
> Sicherheit > Anmeldung > [meinTechnischerBenutzername] > Doppel- oder Rechtsklick+EIgenschaften
> Benutzerzuordnung > [Fokus/Klick auf zutreffende Datenbank, die ohnehin für den User aktiviert sein sollte]
> unten "db_owner" aktivieren (bei mir neben "db_datareader", "db_datawriter" und dem default gesetztem "public")
> OK
Stand: MS SQL 2019 / Management-Studio 20.1.10 / 2024-06-29

Viel Erfolg, bb61
 
bb61_ schrieb:
Das oben genannte Verfahren hat den Nachteil, dass nach Modifikation der Procedure, die ggf. ein Delete/Create enthält, die Berechtigung jedes mal neu erteilt werden muss. Ausserdem muss man das für jede SP (=stored procedure) und evtl. auch jeder UDF (userdefined function, nicht getestet) extra zugewiesen werden.

Soll das etwas globaler gelten ohne andererseits zu viele Rechte global zu aktivieren, also z.B. je (z.B. technischem) User für eine spezielle Projekt-Datenbank, funktioniert folgendes:
> Sicherheit > Anmeldung > [meinTechnischerBenutzername] > Doppel- oder Rechtsklick+EIgenschaften
> Benutzerzuordnung > [Fokus/Klick auf zutreffende Datenbank, die ohnehin für den User aktiviert sein sollte]
> unten "db_owner" aktivieren (bei mir neben "db_datareader", "db_datawriter" und dem default gesetztem "public")
> OK
Stand: MS SQL 2019 / Management-Studio 20.1.10 / 2024-06-29

Viel Erfolg, bb61
Zum Vergrößern anklicken....
Das ist halt die Holzhammermethode wenn mans nicht besser weiß.
 
kleinUNDhilflos schrieb:
Hallo Zusammen,

ich habe einen User der in der Datenbankrolle: "db_datareader" ist.

Ein "SELECT" auf irgendeine Tabelle klappt auch ganz wunderbar. Jetzt möchte ich eine Prozedur ausführen, dazu habe ich als dbo einen Rechtsklick auf die Prozedur gemacht und bei Berechtigungen den User mit Ausführen -> Erteilen ein Häckchen gemacht.
Da ich in der Prozedur einen Benutzerdefinierten Tabellentyp verwende habe ich auch bei diesem dem User die Rechte "Definition anzeigen" und "Verweis" gegeben.

Wenn ich nun versuche mit dem User die Prozedur auszuführen erhalte ich:
"Meldung 229, Ebene 14, Status 5, Zeile 0
Die EXECUTE-Berechtigung wurde für das StaDa_Tabletype-Objekt, XXX-Datenbank, dbo-Schema, verweigert."

Was habe ich vergessen?

Vielen Dank


Gruß Uwe
Zum Vergrößern anklicken....
Probier mal den Code der SP im entsprechenden Userkontext auszuführen (execute as login = <login> oder execute as user = <user>) und schau was genau nicht geht.
 
t-sql schrieb:
Das ist halt die Holzhammermethode wenn mans nicht besser weiß.
Zum Vergrößern anklicken....
Natürlich weiß man's besser. Aber eben genau darum:
Warum schrieb ich wohl von "technischen User in spezieller Projektdatenbank", der/die natürlich eine gekapselte Prozess-Umgebung darstellen, was seinerseits sehr wohl die gleich wirksame "Sicherheitsschicht außenherum" darstellt und keinesfalls vergessen werden darf. Sicherheit hat sehr wohl auch etwas mit Wartbarkeit, Strukturiertheit und Übersichtlichkeit zu tun. Wer schon mal ernsthaft einige hundert DB-Moduln, evtl. auch noch in jahrelanger Weiterentwicklung und Anpassung zu tun hatte, wird sich über permanente Zusatzarbeit zur redundanten Berechtigungsvergabe usw. nach jeder Mini-Anpassung bedanken und mit statistischer Sicherheit auch noch neue Fehler oder Lücken verursachen! Strukturiertheit ist eben nicht nur der Code- sondern der gesamte Prozessentwurf, inkl. der Modul-Lifetime-Zyklen.

Natürlich ist bei nutzer- oder netzwerkoffenen Lösungen mit Gefahr von Schadfunktionen oder Eingriff durch Fremdcode oder -benutzung die Situation eine andere! Hat eben alles seine Berechtigung. In jeweils seiner Umgebung.

Natürlich könnte man ansonsten ja auch "aus Sicherheitsgründen" auf redundanzfreie Code-Konzepte verzichten, also besser an jeder benutzende Stelle ansonsten in Prozeduren und Funktionen zentralisierte Funktionalität "plain" implementieren. Immerhin würde dadurch dann der "single point of failure" bzw. "... attack" dezentralisiert. - Das wäre sicher ebenso ein Holzhammer aus der Werkstatt der "läuft ja, nach mir die Sintflut, Wartung geht mich nix mehr an"-Fraktion.

Schönen Sonntag noch.
 
Werbung:
bb61_ schrieb:
Natürlich weiß man's besser. Aber eben genau darum:
Warum schrieb ich wohl von "technischen User in spezieller Projektdatenbank", der/die natürlich eine gekapselte Prozess-Umgebung darstellen, was seinerseits sehr wohl die gleich wirksame "Sicherheitsschicht außenherum" darstellt und keinesfalls vergessen werden darf. Sicherheit hat sehr wohl auch etwas mit Wartbarkeit, Strukturiertheit und Übersichtlichkeit zu tun. Wer schon mal ernsthaft einige hundert DB-Moduln, evtl. auch noch in jahrelanger Weiterentwicklung und Anpassung zu tun hatte, wird sich über permanente Zusatzarbeit zur redundanten Berechtigungsvergabe usw. nach jeder Mini-Anpassung bedanken und mit statistischer Sicherheit auch noch neue Fehler oder Lücken verursachen! Strukturiertheit ist eben nicht nur der Code- sondern der gesamte Prozessentwurf, inkl. der Modul-Lifetime-Zyklen.

Natürlich ist bei nutzer- oder netzwerkoffenen Lösungen mit Gefahr von Schadfunktionen oder Eingriff durch Fremdcode oder -benutzung die Situation eine andere! Hat eben alles seine Berechtigung. In jeweils seiner Umgebung.

Natürlich könnte man ansonsten ja auch "aus Sicherheitsgründen" auf redundanzfreie Code-Konzepte verzichten, also besser an jeder benutzende Stelle ansonsten in Prozeduren und Funktionen zentralisierte Funktionalität "plain" implementieren. Immerhin würde dadurch dann der "single point of failure" bzw. "... attack" dezentralisiert. - Das wäre sicher ebenso ein Holzhammer aus der Werkstatt der "läuft ja, nach mir die Sintflut, Wartung geht mich nix mehr an"-Fraktion.

Schönen Sonntag noch.
Zum Vergrößern anklicken....
Na, hört sich sehr nach "keinerlei Sicherheits bzw. Rechtekonzept" vorhanden Post. Also eigentlich ein mimimi
 
Zurück
Oben