privilèges sur vues/synonymes vs sur les tables sous-jacentes

Question

En se référant à here et here

Est-ce qu'un utilisateur ont besoin des deux SELECT /INSERT/DELETE/UPDATE, etc. privilèges sur la vue et sur la table sous-jacente pour être en mesure d'effectuer ces actions? Ou des privilèges sur l'une ou l'autre table/vue suffit? En d'autres termes, considérons un utilisateur A possédant la table T et la vue V (construite à partir de T). Est-ce qu'un utilisateur B avec SELECT à droite sur V peut exécuter SELECT s'il ne fait pas SELECT directement sur T, et vice versa? S'il le pouvait, cela ne signifierait-il pas que le privilège View "remplace" le privilège de la table, puisque A ne lui donne pas le droit sur T?

Mise à jour

Dans une question connexe, que diriez-vous synonyme? D'après ce que je comprends dans un livre, les utilisateurs ont besoin des deux privilèges SELECT sur le synonyme et la table sous-jacente. Ce sera différent des vues. Par contre, Oracle semble indiquer que les synonymes se comportent comme des vues.

Un utilisateur peut se voir accorder le privilège SELECT sur un synonyme ou une vue sans être explicitement accordé le privilège SELECT sur la table d'origine

Mise à jour 2

Suite à la réponse de tout le monde que nous avons seulement besoin des privilèges sur la vue pour sélectionner la table (au moins ce que la vue voit de la table) et aucun privilège sur la table n'est nécessaire, considérons ce scénario:

• Tableau T appartient à un
• A GRANT SELECT ON T à B (sans option GRANT)
• B CREATE VIEW V AS SELECT * FROM A
• B GRANT SELECT ON V TO C
• C exécuter SELECT * FROM BV

d'après ce que vous avez dit, C sera en mesure de choisir FRO m V, donc équivalent à la sélection de T. Est-ce que c'est de la triche? B laisse effectivement C voir A.T bien que C n'ait pas le droit sur T et B n'a pas d'OPTION DE SUBVENTION. Y a-t-il un trou de sécurité quelque part?

Answer 1

L'une des utilisations fondamentales des vues est de protéger la confidentialité. Une table de base peut contenir des informations confidentielles que certains utilisateurs n'ont pas besoin de voir (par exemple, dans une table d'employés, vous pouvez avoir un salaire). Certains utilisateurs ont besoin d'accéder à la requête (select), ou de mettre à jour, seulement certains champs de la table de base, sans avoir accès à l'information complète. Par exemple: sélectionnez un numéro de téléphone, ou mettez à jour l'adresse (mais pas d'accès pour voir le salaire ou le bonus). Ensuite, on créerait une vue et donnerait à ces utilisateurs des privilèges "select" et "update" sur la vue seulement, et non sur la table de base. (Le select va toujours contre la table de base, mais les COLUMNS seront limités à ceux inclus dans la vue ... des mises à jour peuvent/seront apportées à la table de base, mais encore une fois, uniquement pour les valeurs incluses dans la vue.La vue peut limiter non seulement les colonnes, mais aussi les lignes - par exemple, avec une clause WHERE dans la vue, vous pouvez exclure complètement le PDG de la vue. Donc, l'une des utilisations principales des vues est exactement basée sur cela: certains utilisateurs peuvent avoir des privilèges sur la vue, mais pas sur la table de base.

Answer 2

Oui. Généralement, la vue s'exécute en tant que propriétaire de la vue et l'utilisateur s'exécute avec l'autorisation sur la vue. L'utilisateur b n'a donc besoin que d'un accès à la vue. Toutefois, lorsque vous examinez ce type de question, vous pouvez également vous intéresser à la sécurité au niveau de la ligne. Cela fonctionne en accordant l'accès à une partie de la table à un utilisateur ou groupe donné (c'est-à-dire en appliquant efficacement les clauses where à la fin des requêtes). Selon votre cas d'utilisation, il peut être plus simple ou plus complexe à gérer.