ORACLE > interdire les opérations DDL (alter table, alter view, etc...)
9 réponses
Flox
Bonjour,
Je suis sous ORACLE 10g et je souhaite interdire toutes op=E9rations
touchant =E0 la structure de ma base. Et cela y compris pour les
propri=E9taires des tables.
Il est clair que cette op=E9ration doit =EAtre possible via un trigger.
Mais est-ce que l'un d'entre vous aurait une autre solution plus
simple =E0 mettre en oeuvre que de distribuer du code PL sur tous mes
sch=E9mas ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
see
Bonjour,
Flox wrote:
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations touchant à la structure de ma base. Et cela y compris pour les propriétaires des tables.
Pourquoi ne pas restreindre l'accès à l'utilisateur propriétaire. Ce serait quand même beaucoup plus simple... -- Bruno http://errance.lirano.net (photographies)
Bonjour,
Flox <florian.testud@gmail.com> wrote:
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations
touchant à la structure de ma base. Et cela y compris pour les
propriétaires des tables.
Pourquoi ne pas restreindre l'accès à l'utilisateur propriétaire. Ce
serait quand même beaucoup plus simple...
--
Bruno
http://errance.lirano.net (photographies)
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations touchant à la structure de ma base. Et cela y compris pour les propriétaires des tables.
Pourquoi ne pas restreindre l'accès à l'utilisateur propriétaire. Ce serait quand même beaucoup plus simple... -- Bruno http://errance.lirano.net (photographies)
Flox
On 16 nov, 21:32, (Bruno Jargot) wrote:
Bonjour,
Flox wrote: > Je suis sous ORACLE 10g et je souhaite interdire toutes opérations > touchant à la structure de ma base. Et cela y compris pour les > propriétaires des tables.
Pourquoi ne pas restreindre l'accès à l'utilisateur propriétaire. Ce serait quand même beaucoup plus simple... -- Brunohttp://errance.lirano.net(photographies)
Bonjour,
En fait, je souhaite également interdire ce type d'opération pour le propriétaire. D'où mon problème... Personnellement, je ne vois que 2 solution : x triggers sur l'ensemble de mes schémas ou créer un système de comptes utilisateurs utilisant des synonymes... Si je n'ai que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Merci de votre aide,
Flo
On 16 nov, 21:32, s...@reply-to.invalid (Bruno Jargot) wrote:
Bonjour,
Flox <florian.tes...@gmail.com> wrote:
> Je suis sous ORACLE 10g et je souhaite interdire toutes opérations
> touchant à la structure de ma base. Et cela y compris pour les
> propriétaires des tables.
Pourquoi ne pas restreindre l'accès à l'utilisateur propriétaire. Ce
serait quand même beaucoup plus simple...
--
Brunohttp://errance.lirano.net(photographies)
Bonjour,
En fait, je souhaite également interdire ce type d'opération pour le
propriétaire. D'où mon problème... Personnellement, je ne vois que 2
solution : x triggers sur l'ensemble de mes schémas ou créer un
système de comptes utilisateurs utilisant des synonymes... Si je n'ai
que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Flox wrote: > Je suis sous ORACLE 10g et je souhaite interdire toutes opérations > touchant à la structure de ma base. Et cela y compris pour les > propriétaires des tables.
Pourquoi ne pas restreindre l'accès à l'utilisateur propriétaire. Ce serait quand même beaucoup plus simple... -- Brunohttp://errance.lirano.net(photographies)
Bonjour,
En fait, je souhaite également interdire ce type d'opération pour le propriétaire. D'où mon problème... Personnellement, je ne vois que 2 solution : x triggers sur l'ensemble de mes schémas ou créer un système de comptes utilisateurs utilisant des synonymes... Si je n'ai que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Merci de votre aide,
Flo
Thierry Thomas
Lundi 19 novembre 2007 à 08:20 GMT, Flox a écrit :
Bonjour,
Bonjour,
En fait, je souhaite également interdire ce type d'opération pour le propriétaire. D'où mon problème... Personnellement, je ne vois que 2 solution : x triggers sur l'ensemble de mes schémas ou créer un système de comptes utilisateurs utilisant des synonymes... Si je n'ai que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Je ne sais pas d'où vient ce besoin, mais j'aurais tendance à dire que vous n'avez pas créé ces objets avec le bon propriétaire. Créez donc plutôt vos objets avec un autre utilisateur, et attribuez les bons droits au propriétaire actuel.
Autrement, vous pouvez aussi n'attribuer les droits de DML qu'au moment de la création initiale des objets, et les retirer ensuite (pas testé, mais ça devrait marcher...). -- Th. Thomas.
Lundi 19 novembre 2007 à 08:20 GMT, Flox a écrit :
Bonjour,
Bonjour,
En fait, je souhaite également interdire ce type d'opération pour le
propriétaire. D'où mon problème... Personnellement, je ne vois que 2
solution : x triggers sur l'ensemble de mes schémas ou créer un
système de comptes utilisateurs utilisant des synonymes... Si je n'ai
que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Je ne sais pas d'où vient ce besoin, mais j'aurais tendance à dire que
vous n'avez pas créé ces objets avec le bon propriétaire. Créez donc
plutôt vos objets avec un autre utilisateur, et attribuez les bons
droits au propriétaire actuel.
Autrement, vous pouvez aussi n'attribuer les droits de DML qu'au moment
de la création initiale des objets, et les retirer ensuite (pas testé,
mais ça devrait marcher...).
--
Th. Thomas.
Lundi 19 novembre 2007 à 08:20 GMT, Flox a écrit :
Bonjour,
Bonjour,
En fait, je souhaite également interdire ce type d'opération pour le propriétaire. D'où mon problème... Personnellement, je ne vois que 2 solution : x triggers sur l'ensemble de mes schémas ou créer un système de comptes utilisateurs utilisant des synonymes... Si je n'ai que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Je ne sais pas d'où vient ce besoin, mais j'aurais tendance à dire que vous n'avez pas créé ces objets avec le bon propriétaire. Créez donc plutôt vos objets avec un autre utilisateur, et attribuez les bons droits au propriétaire actuel.
Autrement, vous pouvez aussi n'attribuer les droits de DML qu'au moment de la création initiale des objets, et les retirer ensuite (pas testé, mais ça devrait marcher...). -- Th. Thomas.
see
Flox wrote:
En fait, je souhaite également interdire ce type d'opération pour le propriétaire. D'où mon problème... Personnellement, je ne vois que 2 solution : x triggers sur l'ensemble de mes schémas ou créer un système de comptes utilisateurs utilisant des synonymes... Si je n'ai que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
La pratique habituelle pour gérer les droits est :
-> Création de tous les objets de l'application avec le compte propriétaire. Ce compte n'est utilisé que pour la création/modification des objets de l'applications.
-> Les utilisateurs de l'application utilisent soit des comptes nominatifs, soit un compte générique. En aucun cas, les utilisateurs utilisent le compte propriétaire. Les droits nécessaires (et seulement les droits nécessaires du genre select, update, delete et insert) sont attribués aux comptes utilisés par les utilisateurs de l'application. Des synonymes publiques ou privés rendent transparent l'accès aux objets de la base (il est même possible de mettre un trigger au logon qui change le schéma par défaut (alter session set current_schema=<user propriétaire des objets de la base>;). Cela permet d'éviter la création de synonymes)
Je ne vois pas de cas où il serait nécessaire de créer une usine à gaz pour empêcher le propriétaire de modifier ses propres objets, en supposant que c'est possible. -- Bruno http://errance.lirano.net (photographies)
Flox <florian.testud@gmail.com> wrote:
En fait, je souhaite également interdire ce type d'opération pour le
propriétaire. D'où mon problème... Personnellement, je ne vois que 2
solution : x triggers sur l'ensemble de mes schémas ou créer un
système de comptes utilisateurs utilisant des synonymes... Si je n'ai
que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
La pratique habituelle pour gérer les droits est :
-> Création de tous les objets de l'application avec le compte
propriétaire. Ce compte n'est utilisé que pour la création/modification
des objets de l'applications.
-> Les utilisateurs de l'application utilisent soit des comptes
nominatifs, soit un compte générique. En aucun cas, les utilisateurs
utilisent le compte propriétaire.
Les droits nécessaires (et seulement les droits nécessaires du genre
select, update, delete et insert) sont attribués aux comptes utilisés
par les utilisateurs de l'application. Des synonymes publiques ou privés
rendent transparent l'accès aux objets de la base (il est même possible
de mettre un trigger au logon qui change le schéma par défaut (alter
session set current_schema=<user propriétaire des objets de la base>;).
Cela permet d'éviter la création de synonymes)
Je ne vois pas de cas où il serait nécessaire de créer une usine à gaz
pour empêcher le propriétaire de modifier ses propres objets, en
supposant que c'est possible.
--
Bruno
http://errance.lirano.net (photographies)
En fait, je souhaite également interdire ce type d'opération pour le propriétaire. D'où mon problème... Personnellement, je ne vois que 2 solution : x triggers sur l'ensemble de mes schémas ou créer un système de comptes utilisateurs utilisant des synonymes... Si je n'ai que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
La pratique habituelle pour gérer les droits est :
-> Création de tous les objets de l'application avec le compte propriétaire. Ce compte n'est utilisé que pour la création/modification des objets de l'applications.
-> Les utilisateurs de l'application utilisent soit des comptes nominatifs, soit un compte générique. En aucun cas, les utilisateurs utilisent le compte propriétaire. Les droits nécessaires (et seulement les droits nécessaires du genre select, update, delete et insert) sont attribués aux comptes utilisés par les utilisateurs de l'application. Des synonymes publiques ou privés rendent transparent l'accès aux objets de la base (il est même possible de mettre un trigger au logon qui change le schéma par défaut (alter session set current_schema=<user propriétaire des objets de la base>;). Cela permet d'éviter la création de synonymes)
Je ne vois pas de cas où il serait nécessaire de créer une usine à gaz pour empêcher le propriétaire de modifier ses propres objets, en supposant que c'est possible. -- Bruno http://errance.lirano.net (photographies)
Flox
On 19 nov, 19:31, Thierry Thomas wrote:
Lundi 19 novembre 2007 à 08:20 GMT, Flox a écrit :
> Bonjour,
Bonjour,
> En fait, je souhaite également interdire ce type d'opération pour l e > propriétaire. D'où mon problème... Personnellement, je ne vois qu e 2 > solution : x triggers sur l'ensemble de mes schémas ou créer un > système de comptes utilisateurs utilisant des synonymes... Si je n'ai > que ces 2 solutions, je pense plutôt me pencher sur la solution PL... > Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Je ne sais pas d'où vient ce besoin, mais j'aurais tendance à dire que vous n'avez pas créé ces objets avec le bon propriétaire. Créez do nc plutôt vos objets avec un autre utilisateur, et attribuez les bons droits au propriétaire actuel.
Autrement, vous pouvez aussi n'attribuer les droits de DML qu'au moment de la création initiale des objets, et les retirer ensuite (pas testé, mais ça devrait marcher...). -- Th. Thomas.
Bonjour,
Je suis d'accord avec vous : cela aurait été plus simple d'avoir d'autres propriétaires.
Pour expliquer un peu mieux mon besoin, voici ce que je souhaite faire. Nous avons 1 environnement de qualif et 1 de prod qui sont identiques (même schémas, même user, même tables, etc...). Les droit s sont également identiques. Maintenant, je souhaite interdire les opérations de manipulation de la structure des tables de production (alter ou drop table par exemple) afin d'obtenir un environnement stable et demander aux développeurs de respecter un workflow pour modification de la production.
C'est pour cela que même les propriétaires des objets doivent être bloqués (à l'exception des comptes ORACLE).
Voilà, j'espère que cela éclaire un peu mieux le sujet de cette demande peu conventionelle....
Encore merci de votre aide,
Flo.
On 19 nov, 19:31, Thierry Thomas <ttho...@mail.dotcom.fr> wrote:
Lundi 19 novembre 2007 à 08:20 GMT, Flox a écrit :
> Bonjour,
Bonjour,
> En fait, je souhaite également interdire ce type d'opération pour l e
> propriétaire. D'où mon problème... Personnellement, je ne vois qu e 2
> solution : x triggers sur l'ensemble de mes schémas ou créer un
> système de comptes utilisateurs utilisant des synonymes... Si je n'ai
> que ces 2 solutions, je pense plutôt me pencher sur la solution PL...
> Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Je ne sais pas d'où vient ce besoin, mais j'aurais tendance à dire que
vous n'avez pas créé ces objets avec le bon propriétaire. Créez do nc
plutôt vos objets avec un autre utilisateur, et attribuez les bons
droits au propriétaire actuel.
Autrement, vous pouvez aussi n'attribuer les droits de DML qu'au moment
de la création initiale des objets, et les retirer ensuite (pas testé,
mais ça devrait marcher...).
--
Th. Thomas.
Bonjour,
Je suis d'accord avec vous : cela aurait été plus simple d'avoir
d'autres propriétaires.
Pour expliquer un peu mieux mon besoin, voici ce que je souhaite
faire. Nous avons 1 environnement de qualif et 1 de prod qui sont
identiques (même schémas, même user, même tables, etc...). Les droit s
sont également identiques. Maintenant, je souhaite interdire les
opérations de manipulation de la structure des tables de production
(alter ou drop table par exemple) afin d'obtenir un environnement
stable et demander aux développeurs de respecter un workflow pour
modification de la production.
C'est pour cela que même les propriétaires des objets doivent être
bloqués (à l'exception des comptes ORACLE).
Voilà, j'espère que cela éclaire un peu mieux le sujet de cette
demande peu conventionelle....
Lundi 19 novembre 2007 à 08:20 GMT, Flox a écrit :
> Bonjour,
Bonjour,
> En fait, je souhaite également interdire ce type d'opération pour l e > propriétaire. D'où mon problème... Personnellement, je ne vois qu e 2 > solution : x triggers sur l'ensemble de mes schémas ou créer un > système de comptes utilisateurs utilisant des synonymes... Si je n'ai > que ces 2 solutions, je pense plutôt me pencher sur la solution PL... > Mais si l'un de vous à une autre idée, elle est la bienvenue ;-)
Je ne sais pas d'où vient ce besoin, mais j'aurais tendance à dire que vous n'avez pas créé ces objets avec le bon propriétaire. Créez do nc plutôt vos objets avec un autre utilisateur, et attribuez les bons droits au propriétaire actuel.
Autrement, vous pouvez aussi n'attribuer les droits de DML qu'au moment de la création initiale des objets, et les retirer ensuite (pas testé, mais ça devrait marcher...). -- Th. Thomas.
Bonjour,
Je suis d'accord avec vous : cela aurait été plus simple d'avoir d'autres propriétaires.
Pour expliquer un peu mieux mon besoin, voici ce que je souhaite faire. Nous avons 1 environnement de qualif et 1 de prod qui sont identiques (même schémas, même user, même tables, etc...). Les droit s sont également identiques. Maintenant, je souhaite interdire les opérations de manipulation de la structure des tables de production (alter ou drop table par exemple) afin d'obtenir un environnement stable et demander aux développeurs de respecter un workflow pour modification de la production.
C'est pour cela que même les propriétaires des objets doivent être bloqués (à l'exception des comptes ORACLE).
Voilà, j'espère que cela éclaire un peu mieux le sujet de cette demande peu conventionelle....
Encore merci de votre aide,
Flo.
nobody
C'est pour cela que même les propriétaires des objets doivent être bloqués (à l'exception des comptes ORACLE).
Voilà, j'espère que cela éclaire un peu mieux le sujet de cette demande peu conventionelle....
Encore merci de votre aide,
Flo.
la sécurité est en effet peu conventionnelle avec Oracle
UN DEMI-MILLION DE BASES DE DONNEES SANS PROTECTION SUR INTERNET (15/11/07) Près d'un demi-million de serveurs de bases de données Oracle et Microsoft sont laissés sans protection et sont accessibles librement depuis Internet. C'est ce qu'affirme le chercheur en sécurité David Litchfield [...]. http://www.secuser.com/article.php?ID945
C'est pour cela que même les propriétaires des objets doivent être
bloqués (à l'exception des comptes ORACLE).
Voilà, j'espère que cela éclaire un peu mieux le sujet de cette
demande peu conventionelle....
Encore merci de votre aide,
Flo.
la sécurité est en effet peu conventionnelle avec Oracle
UN DEMI-MILLION DE BASES DE DONNEES SANS PROTECTION SUR INTERNET (15/11/07)
Près d'un demi-million de serveurs de bases de données Oracle et Microsoft
sont laissés sans protection et sont accessibles librement depuis Internet.
C'est ce qu'affirme le chercheur en sécurité David Litchfield [...].
http://www.secuser.com/article.php?ID945
C'est pour cela que même les propriétaires des objets doivent être bloqués (à l'exception des comptes ORACLE).
Voilà, j'espère que cela éclaire un peu mieux le sujet de cette demande peu conventionelle....
Encore merci de votre aide,
Flo.
la sécurité est en effet peu conventionnelle avec Oracle
UN DEMI-MILLION DE BASES DE DONNEES SANS PROTECTION SUR INTERNET (15/11/07) Près d'un demi-million de serveurs de bases de données Oracle et Microsoft sont laissés sans protection et sont accessibles librement depuis Internet. C'est ce qu'affirme le chercheur en sécurité David Litchfield [...]. http://www.secuser.com/article.php?ID945
Jerome Vitalis
On Fri, 16 Nov 2007 07:31:40 -0800, Flox wrote:
Bonjour,
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations touchant à la structure de ma base. Et cela y compris pour les propriétaires des tables.
Il est clair que cette opération doit être possible via un trigger. Mais est-ce que l'un d'entre vous aurait une autre solution plus simple à mettre en oeuvre que de distribuer du code PL sur tous mes schémas ?
Merci de votre aide et à bientôt.
Flo.
Avec : revoke alter any table from <user>;
et commandes similaires pour les autres types d'objets du schéma.
On Fri, 16 Nov 2007 07:31:40 -0800, Flox wrote:
Bonjour,
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations
touchant à la structure de ma base. Et cela y compris pour les
propriétaires des tables.
Il est clair que cette opération doit être possible via un trigger. Mais
est-ce que l'un d'entre vous aurait une autre solution plus simple à
mettre en oeuvre que de distribuer du code PL sur tous mes schémas ?
Merci de votre aide et à bientôt.
Flo.
Avec :
revoke alter any table from <user>;
et commandes similaires pour les autres types d'objets du schéma.
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations touchant à la structure de ma base. Et cela y compris pour les propriétaires des tables.
Il est clair que cette opération doit être possible via un trigger. Mais est-ce que l'un d'entre vous aurait une autre solution plus simple à mettre en oeuvre que de distribuer du code PL sur tous mes schémas ?
Merci de votre aide et à bientôt.
Flo.
Avec : revoke alter any table from <user>;
et commandes similaires pour les autres types d'objets du schéma.
Oups. Désolé, j'ai répondu trop vite, ça ne fonctionnera pas, surtout pour le propriétaire du schéma (qui n'a pas besoin d'avoir ces privilèges pour modifier ses objets.) ----- échangez opinions et commentaires dans les forums de discussion. http://www.usenetgratuit.com/
Oups. Désolé, j'ai répondu trop vite, ça ne fonctionnera pas, surtout pour
le propriétaire du schéma (qui n'a pas besoin d'avoir ces privilèges pour
modifier ses objets.)
-----
échangez opinions et commentaires dans les forums de discussion.
http://www.usenetgratuit.com/
Oups. Désolé, j'ai répondu trop vite, ça ne fonctionnera pas, surtout pour le propriétaire du schéma (qui n'a pas besoin d'avoir ces privilèges pour modifier ses objets.) ----- échangez opinions et commentaires dans les forums de discussion. http://www.usenetgratuit.com/
astalavista
alter table disable table lock
interdit tous les DDL mais autorise les DML ...
----- Original Message ----- From: "Flox" Newsgroups: fr.comp.applications.sgbd Sent: Friday, November 16, 2007 4:31 PM Subject: ORACLE > interdire les opérations DDL (alter table, alter view, etc...)
Bonjour,
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations touchant à la structure de ma base. Et cela y compris pour les propriétaires des tables.
Il est clair que cette opération doit être possible via un trigger. Mais est-ce que l'un d'entre vous aurait une autre solution plus simple à mettre en oeuvre que de distribuer du code PL sur tous mes schémas ?
Merci de votre aide et à bientôt.
Flo.
alter table disable table lock
interdit tous les DDL mais autorise les DML ...
----- Original Message -----
From: "Flox" <florian.testud@gmail.com>
Newsgroups: fr.comp.applications.sgbd
Sent: Friday, November 16, 2007 4:31 PM
Subject: ORACLE > interdire les opérations DDL (alter table, alter view,
etc...)
Bonjour,
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations
touchant à la structure de ma base. Et cela y compris pour les
propriétaires des tables.
Il est clair que cette opération doit être possible via un trigger.
Mais est-ce que l'un d'entre vous aurait une autre solution plus
simple à mettre en oeuvre que de distribuer du code PL sur tous mes
schémas ?
----- Original Message ----- From: "Flox" Newsgroups: fr.comp.applications.sgbd Sent: Friday, November 16, 2007 4:31 PM Subject: ORACLE > interdire les opérations DDL (alter table, alter view, etc...)
Bonjour,
Je suis sous ORACLE 10g et je souhaite interdire toutes opérations touchant à la structure de ma base. Et cela y compris pour les propriétaires des tables.
Il est clair que cette opération doit être possible via un trigger. Mais est-ce que l'un d'entre vous aurait une autre solution plus simple à mettre en oeuvre que de distribuer du code PL sur tous mes schémas ?
