Créer un autre

Question

J'essayais de créer un nouveau rôle qui aura tous les privilèges du rôle PUBLIC, puis de supprimer tous les privilèges du rôle PUBLIC par la suite. C'est pour des raisons de sécurité.

C'est le problème. Je ne pouvais pas accorder SYS./1005bd30_LnkdConstant, et d'autres avec le même format, à mon nouveau rôle.

échantillon

:

SYS./10076b23_OraCustomDatumClosur SYS./100c1606_StandardMidiFileRead ORDSYS./1013c29d_PlanarImageServerPro . . .

Ai-je vraiment besoin de ceux-ci ou mon nouveau rôle "public" peut faire sans ceux-ci?

Toute aide sera grandement appréciée.

Answer 1

Permettez-moi de deviner rapidement ici. Le problème que vous rencontrez est que les noms d'objets sont sensibles à la casse. La solution rapide consiste à placer les noms d'objet entre guillemets, comme ceci.

GRANT EXECUTE ON SYS."/1005bd30_LnkdConstant" TO mynewpublicrole; 

Vous indiquez que vous "ne pouvait pas accorder [EXECUTE ON] SYS./1005bd30_LnkdConstant" à un rôle.
Je prends cela pour dire que lorsque vous avez exécuté l'instruction GRANT, Oracle a soulevé une exception, très probablement,

ORA-00903: invalid table name 

Enfermer le objectname guillemets doubles (comme le montre l'exemple) devrait corriger ce problème.

Il n'est pas possible de répondre à la question de savoir si votre nouveau rôle nécessite un privilège EXECUTE sur ces objets ou non. Eh bien, le rôle n'a pas nécessairement besoin d'eux. La question est de savoir si l'utilisateur en a besoin ou non (qu'il soit accordé directement, ou accordé indirectement par le biais de rôles). Cela peut être déterminé par des tests approfondis.

---

Autres commentaires.

Si votre intention est de créer un nouveau rôle et d'accorder ce rôle à tous les utilisateurs, je ne vois pas que la sécurité est modifiée ou améliorée. Donc, je vais supposer que ce n'est pas le cas.

Il semblerait que vous essayez d'appliquer le principe du «moindre privilège». J'applaudis cet effort. L'un des modèles les plus courants que les développeurs d'applications observent est que l'application se connecte à la base de données en tant que propriétaire des objets de schéma. Cela signifie que l'application dispose de toutes sortes de privilèges dont elle n'a probablement pas besoin, par ex. DROP TABLE, ALTER PROCEDURE, etc.

Le motif que nous utilisons est d'avoir un utilisateur "propriétaire" qui possède les objets de schéma, et un utilisateur "APP" distinct qui a des privilèges spécifiques dont il a besoin sur les objets "propriétaire", et des synonymes pour les objets "OWNER". (Les synonymes permettent de référencer OWNER.object sans être qualifié avec le propriétaire.) Cela va presque sans dire, nous n'accordons pas de privilèges à PUBLIC, nous accordons des rôles là où c'est nécessaire. Je mentionne cela parce que c'est un modèle que nous utilisons pour mettre en œuvre le principe du «moindre privilège».

---

Pour d'autres problèmes de sécurité, je vous recommande de consulter le livre blanc « Liste de contrôle Oracle de sécurité »:

http://www.oracle.com/technology/deploy/security/database-security/pdf/twp_security_checklist_database.pdf

---

D'autres exceptions possibles que vous avez pu rencontrer lors de l'exécution de l'instruction GRANT :

ORA-01031: insufficient privileges 

ouDans l'un ou l'autre de ces cas, assurez-vous de vous connecter à la base de données en tant que SYS (SYSDBA) pour accorder les privilèges. Nous accordons presque toujours des privilèges en tant que propriétaire de l'objet, plutôt que d'avoir un autre utilisateur comme GRANTEE. Je n'utilise presque jamais le "WITH GRANT OPTION" sur les privilèges d'objet. C'est un modèle plus simple, et évite tout problème potentiel avec les arbres de dépendances.