2010-02-17 13 views
0

J'ai essayé d'accorder CONNECT à un utilisateur via un rôle:Subventions par rôle modifié dans Oracle 11g?

CREATE ROLE my_role IDENTIFIED BY "passwd"; 
GRANT CONNECT TO my_role; 

CREATE USER my_user IDENTIFIED BY "passwd"; 
GRANT my_role TO my_user; 

Lorsque je tente cela dans 10g il fonctionne très bien, alors que dans 11g connexion est rejeté:

ORA-01045:user MY_USER lacks CREATE SESSION privilege; logon denied

Accorder CREATE SESSION au rôle ne fait pas de différence.
Je ne peux me connecter qu'après avoir accordé CONNECT (ou CREATE SESSION) directement à l'utilisateur. Est-ce que Oracle a changé ce comportement ou est-ce que je fais quelque chose de mal?

Répondre

6

Je pense que vous pourriez avoir obtenu une «caractéristique» de sécurité dans 10g. La façon dont j'ai lu le Guide de référence et de sécurité SQL pour 11g indique que les rôles activés par mot de passe nécessitent l'utilisation du SET ROLE my_role IDENTIFIED BY passwd avant que les droits accordés par ce rôle soient effectifs.

Vous ne pouvez pas CREATE SESSION jusqu'à ce que vous ayez le rôle, et vous ne pouvez pas avoir le rôle jusqu'à ce que vous émettiez SET ROLE.

Catch-22.

+0

Excellent, merci beaucoup! Avez-vous un lien où cela est indiqué? –

+0

Je n'ai pas de lien vers la documentation de tahiti.oracle.com, car sa disponibilité n'est pas fiable. La syntaxe CREATE ROLE et SET ROLE se trouve dans Oracle Database SQL Language Reference 11g version 2 (E10592-04) sur les pages 15-59 et 19-60 respectivement. –

1

L'activation des rôles par défaut (accordés à un utilisateur par défaut) qui sont également protégés par mot de passe a été modifiée dans Oracle 10g, version 10.2.0.5 (au moins pour notre copie). Dans la version 10.2.0.5, un rôle protégé par mot de passe ne serait plus activé par défaut. Il devait être spécifiquement activé avec le mot de passe approprié.

Cela n'a pas été documenté pour autant que nous le sachions. Mais lorsque nos systèmes ont été mis à jour de 10.2.0.4 à 10.2.0.5, cette modification a brisé plusieurs de nos systèmes, et nous avons dû créer des rôles parallèles non protégés pour nos comptes fonctionnels qui n'avaient aucun mécanisme pour activer les rôles par défaut. Nous avons essentiellement créé old_role_batch sans mot de passe comme une copie de old_role qui était protégé par un mot de passe.

2

La base de connaissances Oracle [ID 745407.1] l'explique.

La clause DEFAULT dans les:

alter rôles utilisateur par défaut; spécifie les rôles accordés par défaut à l'utilisateur lors de l'ouverture de session. Cette clause peut contenir uniquement les rôles accordés directement à l'utilisateur avec une instruction GRANT ou les rôles créés par l'utilisateur avec le privilège CREATE ROLE. Vous ne pouvez pas utiliser la clause de rôle par défaut pour permettre:

  1. rôles non accordés à l'utilisateur

  2. rôles accordés par d'autres rôles

  3. rôles gérés par un service externe (tel que le système d'exploitation), ou par Oracle Internet Directory

  4. Rôles authentifiés par mot de passe. Rôles implémentés en tant que rôles d'application sécurisés.

Pour le mot de passe authentifié rôles, le changement a été introduit dans la version 10.2.0.5 et 11.1.0.7. Pour les rôles d'application sécurisés, la modification a été introduite dans les versions Oracle 10.2.0.4 et 11.1.0.7 Ces modifications s'appliqueront à toutes les versions futures. Les restrictions mentionnées ci-dessus seront introduites dans la future documentation.

On peut facilement transformer le mot de passe a permis des rôles dans des rôles standards en exécutant le script résultant de:

select « alter role « || rôle || » non identifié;' de dba_roles où password_required = 'YES' et le rôle n'est pas dans (sélectionnez le rôle de dba_application_roles);