2009-06-08 4 views
0

Voici mon scénario ...Permissions SQL/Securables - Puis-je donner des permissions à un "Select" d'une vue qui utilise une autre vue pour laquelle aucune permission n'a été accordée?

SQL Rôle

  • Staff_User

Schéma

  • Personnes

Tables

  • People.Persons

  • People.PhoneNumbers

Vues

  • People.vtPersons - La vue vtPersons filtre les données de la table Persons qui n'affiche que celles qui appartiennent à l'utilisateur actuellement connecté.

  • People.vtPhoneNumbers - La vue vtPhoneNumbers filtre les données de la table PHONENUMBERS montrant que ce qui appartient à l'utilisateur actuellement connecté.

  • People.vwContactInformation - Le vwContactInformation « View » combine les données de vtPersons et vtPhoneNumbers de sorte qu'il peut être utilisé comme une requête dans un rapport Crystal.

Le rôle Staff_User a été accordée « SELECT » l'autorisation de la vue vwContactInformation et rien d'autre.

Je reçois une erreur maintenant disant que l'autorisation est refusée à l'objet vtPhoneNumbers. Dois-je également accorder l'autorisation "SELECT" à cette vue? D'expérience dans un autre SCHEME je n'ai pas eu à faire cela et tout a bien fonctionné. Mais maintenant je reçois cette erreur dans un second SCHEME que j'ai créé. Quelqu'un peut-il suggérer ce que j'ai dans le premier schéma qui permet aux permissions de cascader aux vues, tables, fonctions etc. qui sont appelées de la vue rendue accessible au rôle.

Merci, Justin

+0

Quel SGBD utilisez-vous? Certains fournisseurs offrent des droits d'invocation et des droits spécifiques. –

+0

Microsoft SQL Server 2008. Je ne pense pas qu'il offre ces comportements spécifiques. – Justin

Répondre

0

En supposant SQL Server (toutes les versions)

L'erreur dit « refusé »: si les autorisations sont manquants ou incorrects, vous verriez quelque chose comme «n'existe pas ou aucune autorisation ". Sur cette base, je vérifierais les droits de vtPhoneNumbers et verifierais si un DENY explicite a été défini. DENY is always evaluated and takes precedence. (Désolé, ne peut pas le trouver dans BOL).

Pourquoi:

L'idée de ownership chains/chaining signifie que si tous les objets sont dans le même schéma (aka propriétaire), ne sont pas vérifiées autorisations sur l'objet référencé.

Dans ce cas, les autorisations sur vtPhoneNumbers et vtPersons ne doivent pas être vérifiées car toutes les vues et tables se trouvent dans le schéma "Personnes".

Remarque, REVOKE supprime les autorisations (précédemment définies à l'aide de GRANT ou DENY). Quelqu'un peut avoir utilisé DENY pas REVOKE pour supprimer une instruction GRANT précédente sur vtPhoneNumbers

Questions connexes