Discussion :

[scheu]

Bonjour

Pour des contraintes de sécurité, je souhaiterais que les utilisateur d'une base ayant le rôle CONNECT ne puissent pas créer de database link. Or, le privilège CREATE DATABASE LINK fait partie du rôle CONNECT (je suis en 9i). Comment leur enlever ce droit ? Est-ce envisageable de modifier le rôle CONNECT pour lui supprimer le privilège DATABASE LINK (bien que ce n'est pas conseillé de modifier les rôles système existants) ? Ou vaut-il mieux leur enlever le rôle CONNECT et ne leur mette que les autres privilèges attribués au rôle CONNECT (create session, ...)

Merci de vos conseils

[orafrance]

bah oui, change CONNECT

[scheu]

Je voulais juste m'en assurer, des fois que changer les rôles système ne serait pas conseillés
...
Merci

[Michel SALAIS]

Il est préférable à mon sens de leur donner un autre rôle qui ne contiendrait pas le privilège et de laisser le rôle CONNECT tel quel ...

[LeoAnderson]

+1
il faut laisser les rôles définis par défaut inchangés mais ne pas les attribuer.
A la place, on créé les rôles "maisons" qui ne contiennent que ce qui va bien, et juste ce dont on a besoin.

Une seule exception tout de même pour le "rôle" PUBLIC auquel il est vivement conseillé de faire des REVOKE...

[orafrance]

Quand même, ça me parait pour le moins dangereux de laisser un privilège aussi important au simple CONNECT

[LeoAnderson]

Quand même, ça me parait pour le moins dangereux de laisser un privilège aussi important au simple CONNECT

et qui c'est qui conseillait de changer connect ?

[orafrance]

Moi

Or, le privilège CREATE DATABASE LINK fait partie du rôle CONNECT (je suis en 9i).

c'est pourquoi je conseille de modifier CONNECT qui visiblement contient une faille de sécurité potentielle

[LeoAnderson]

la faille c'est surtout d'attribuer CONNECT.....

[orafrance]

on peut le voir comme ça aussi en effet

[scheu]

la faille c'est surtout d'attribuer CONNECT.....

Ca c'est vrai je m'en rends compte tous les jours
Merci de vos réponses en tout cas

[LeoAnderson]

Ca c'est vrai je m'en rends compte tous les jours
Merci de vos réponses en tout cas

ce n'était pas une vanne !

C'est une vraie faille d'attribuer le rôle CONNECT.
Il faut attribuer le rôle MON-CONNECT qui a les privilèges CREATE SESSION et ALTER SESSION par exemple.
mais en aucun cas n'attribuer les rôles standards.

[scheu]

ce n'était pas une vanne !

C'est une vraie faille d'attribuer le rôle CONNECT.
Il faut attribuer le rôle MON-CONNECT qui a les privilèges CREATE SESSION et ALTER SESSION par exemple.
mais en aucun cas n'attribuer les rôles standards.

Je n'ai pas pris ça comme une vanne, je suis tout à fait d'accord avec toi sur le principe

[kore62]

Si je peux me permettre, perso je suis d'avis de lui filer le create session... Esquivez d'attribuer le role connect... D'ailleurs je trouve que les rôles par défaut ne sont pas trés bien définis.... m'enfin ca n'engage que moi...

C'est comme lorsqu'on file le grant ressource (si j'ai bonne mémoire) à un user et qu'il se voit alors attribué automatiquement le privilege unlimited tablespace pour son schema.. une abération.. le user peut alors ecrire sur n'importe quel tablespace... c'est pas frais.

Mieux vaut lui virer et lui mettre le "quota unlimited tablespace "sur son tablespace par defaut...

M'enfin pour revenir à nos moutons, NON au grant CONNECT... un grand OUUUIII au grant CREATE SESSION (meilleur controle et sutout plus de sécurité)

[pat29]

Il y a d'ailleurs des choses bizarres dans rôles :
avec CONNECT on peut notamment créer des tables, des vues
avec RESOURCE on peut créer des procédures, des triggers
mais même en ayant ces 2 rôles on ne peut pas créer de MATERIALIZED VIEW ...