2009-06-08 2 views
0

Hier ist mein Szenario ...SQL Permissions/Securables - Kann ich einem "Select" eine Berechtigung aus einer View erteilen, die eine andere View verwendet, für die keine Berechtigung erteilt wurde?

SQL Rolle

  • Staff_User

Scheme

  • Menschen

Tabellen

  • People.Persons

  • People.PhoneNumbers

Ansichten

  • People.vtPersons - Die Ansicht "vtPersons" filtert die Daten aus der Tabelle "Persons", die nur die Daten anzeigen, die zum derzeit angemeldeten Benutzer gehören.

  • People.vtPhoneNumbers - Die vtPhoneNumbers Ansicht filtert die Daten aus der Tabelle nur Phonenumbers, dass zeigen, die derzeit mit dem angemeldeten Benutzer gehört.

  • People.vwContactInformation - Die vwContactInformation "Ansicht" kombiniert die Daten von vtPersons und vtPhoneNumbers so dass es als eine Abfrage in einem Crystal Report verwendet werden kann.

Die Staff_User Rolle der vwContactInformation Ansicht und nichts wurde sonst gewährt „SELECT“ Erlaubnis.

Ich erhalte jetzt eine Fehlermeldung, dass die Berechtigung für das Objekt vtPhoneNumbers verweigert wird. Muss ich dieser Ansicht auch die Berechtigung "SELECT" erteilen? Aus Erfahrung in einem anderen SCHEME musste ich das NICHT machen und alles hat gut funktioniert. Aber jetzt bekomme ich diesen Fehler in einem zweiten SCHEMA, das ich erstellt habe. Kann jemand vorschlagen, was ich im ersten Schema habe, das die Berechtigungen erlaubt, auf Ansichten, Tabellen, Funktionen usw. zu kaskadieren, die aus der Sicht aufgerufen werden, die für die Rolle zugänglich gemacht wird.

Danke, Justin

+0

zu entfernen. Welche DBMS verwenden Sie? Einige Anbieter bieten Rechte zum Aktivieren und Definieren von Rechten an. –

+0

Microsoft SQL Server 2008. Ich denke nicht, dass es diese spezifischen Verhaltensweisen bietet. – Justin

Antwort

0

Unter der Annahme, SQL Server (alle Versionen)

Der Fehler sagt „verweigert“: Wenn Berechtigungen wurden oder falsch fehlt, würden Sie so etwas wie „nicht vorhanden ist oder keine Berechtigungen sehen ". Basierend darauf würde ich die Rechte für vtPhoneNumbers überprüfen und sehen, ob explizit DENY gesetzt wurde. DENY is always evaluated and takes precedence. (Sorry, finde es nicht in BOL).

Warum:

Die Idee ownership chains/chaining bedeutet, dass, wenn alle Objekte im selben Schema (auch bekannt als Eigentümer), Berechtigungen für das referenzierte Objekt sind, werden nicht überprüft.

In diesem Fall sollten die Berechtigungen für vtPhoneNumbers und vtPersons nicht überprüft werden, da sich alle Ansichten und Tabellen im Schema "Personen" befinden.

Hinweis, REVOKE entfernt Berechtigungen (zuvor mit GRANT oder DENY gesetzt). Möglicherweise hat jemand DENY nicht REVOKE verwendet, um eine vorherige GRANT-Anweisung auf vtPhoneNumbers