SP mit UPDATE auf Tabelle, obwohl Benutzer nur READ hat ?

Question

Hi,

ich habe einen Benutzer (USR), der auf der Applikations-DB UPDATE-Berechtigungen hat. Für den Zugriff auf eine HAUPT-DB sind NUR READ-Berechtigungen vergeben. Hier ist der Wunsch, dass die Applikation mit eingeloggtem USR eine SP aufruft, die ein UPDATE auf eine Tabelle in der HAUPT-DB macht, obwohl der Benutzer direkt nur READ-Berechtigung auf diese Tabelle hat. Geht das?

Ich hoffe ich habe das Problem passabel geschildert.

Gruß Hipp

Answer 1

ja.

Du musst die SP nur in einem anderen User Context laufen lassen, welche dann Schreibrechte auf die HauptDB hat:

http://msdn.microsoft.com/en-us/library/ms188354.aspx

am sichersten ist es, wenn Du ein SQL User erstellt fuer welche kein Login definiert wird und welcher nur gerade die benoetigten Rechte zum Schreiben der Tabelle hat.

---

Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

Answer 2

SP aufruft, die ein UPDATE auf eine Tabelle in der HAUPT-DB macht, obwohl der Benutzer direkt nur READ-Berechtigung auf diese Tabelle hat. Geht das?

Hallo Hipp,

das geht ohne weiteres und das zugrunde liegende Konzept nennt sich "Besitzverkettung" (ownership chaining).

Wenn Du einem User die Rechte gibts, eine SP auszuführen, ist es egal, was die SP macht und auf welche Tabellen/Objekte sie zugreift und vor allem, ob der Ausführer Berechtigungen in irgendeiner Art auf die Tabellen hat: Er darf die SP ausführen, und fertig.

Das ist auch eine Basis des Sicherheitskonzeptes, das allgemein genutzt wird: Man gibt keinem User direkten Zugriff auf die Tabellen, sondern stellt nur SPs zum Ändern der Daten zur Verfügung und Views zum Abfragen; die zugrunde liegenden Tabellen sollte für User völlig transparent (= unsichtbar) sein.

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 3

Hallo Olaf,

ist interessant. Da steht nus noch etwas Arbeit bevor. Gibt es irgendwo eie Übersicht, für was die einzelnen Berechtigungen eingesetzt werden? Natürlich ist mir klar, das Löschen für das Löschen von Daten zuständig ist. DOch gibt es z.B. Aktualisieren und Ändern. ??? Authentifizieren und Verbinden ???

Vermutlich hilft jetzt einmal ein Buch, aber wir sind eben erst im Anfangs-Stadium.

Abernoch einmal zurück zu den Usern. Ich habe SP's, die alle in der "master" liegen und auf meine MyMaster zugreift. DIe SP's liegen dort, da es viele verschiedene Anwendungen mit entsprechenden DB'S gibt, die aber alle die MyMaster-DB mit verwenden. Hier liegen Hauptdaten drin. Ichmelde mich also unter UserA mit Zugriff auf ApplicationA an und es erfolgt ein Call der SP_X in der "master". Ein UserB startet mit der ApplicationB und ruft ebenfalls die SP_X in der "master" auf. Was muss ich UserA und B und/oder der SP für eine Berechtigung geben? -> Ausführen? Und verstehe ich das richtig, dass nach Deiner Meinung oder dem zu grunde liegenden Konzept die User eigentlich nur "Anmelden" und "Ausführen" als Berechtigungen hätten? Bei einer ODBC-Einbindung der Tabellen muss ich zumindest "Definitionen anzeigen" haben, sonst sehe ich keine Tabellen :-(

Gruß Hipp

Answer 4

Abernoch einmal zurück zu den Usern. Ich habe SP's, die alle in der "master" liegen und auf meine MyMaster zugreift. DIe SP's liegen dort, da es viele verschiedene Anwendungen mit entsprechenden DB'S gibt, die aber alle die MyMaster-DB mit verwenden. Hier liegen Hauptdaten drin.

Du legst allen ernstes Objekte in der Systemdatenbank "master" an? Das ist natürlich nicht so ganz im Sinne des Erfinders. Dein missglückter Versuch mit dem Logon-Trigger hatte Dir doch wohl gezeigt, wie wichtig die master Datenbank ist.

Und wie soll das dann funktionieren, wenn man z.B. zur Lastenverteilung die eigentliche Applikationsdaten-Bank auf einen anderen Server verschoben wird, muss dann dort auch alle SPs in der master angelegt werden? Dito bei einer Migration.

Zudem würde das für die Berechtigungen wie anfangs gedacht bedeuten, das die Datenbank-übergreifende Besitzverkettung (cross database ownership chaning) aktiviert werden, was im Standard deaktiviert ist und kein vernünftiger SysAdmin aktivieren würde.

Ganz ehrlich, das halte ich für ein sehr unglückliches Design; bei uns bräuchtest Du mit so einem Software/DB Konstrukt nicht vorstellig werden, das ist ein absolutes No-Go.

Zurück zu den Berechtigungen, das die Bezeichnungen auch mit übersetzt wurden, ist hier schon fast hinderlich, den die Englischen Bezeichnung sagen so schon gleich aus, wozu sie da sind. So ist "Aktualisieren" in EN "Alter", also das ändern von Objektdefinitionen, ein "Auswählen" ist ein "Select", "Ausführen" = "Execute" usw.

Hier findest Du detailierte & umfangreiche Informationen zum Thema Sicherheit & Berechtigungen: MSDN Sicherheit und Schutz (Datenbankmodul)

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 5

Um auf den etwas heftigen aber zu Rechten Seitenhieb "No-Go" zu kommen.

Ich bin irgend welchen irrsinnigen Code-Snippets auf den Leim gegangen. Natürlich sollte die MASTER unangetastet bleiben. Habe gerade unsere FN und SP bezüglich FileExists in unsere Haupt-DB verschoben und komme von jeder Applikation aus an diese Komponenten. Somit wandern alle in dies DB.

Da wir Anwendungs-Entwickler sind und bei uns erst ein Aufbau eines SQL-Servers stattfindet, ist das natürlich großes Neuland. Wir werden vermutlich jemanden benötigen, der bei uns in erster Linie solche Aufgaben wahrnehmen wird. Vorerst müssen wir uns aber selbst hineinfinden und außer Literatur muss auch ein Crash-Kurs her, um das Gröbste abzufangen.

So wie ich es sehe, haben wir eine Menge Arbeit vor uns ...

Gruß Hipp