[DB2 UDB 6.1 for LUW] Limiter l'accès dans son propre SCHEMA ?

[CyBeRoN]

Bonjour !
Est-il possible de limiter l'accès sur une table dans son propre SCHEMA ?
J'ai laissé le droit uniquement en SELECT sur une table mais malheureusement, l'utilisateur peut toujours tout faire...

Please help

[jab]

A la ce n'est pas normal, si tu as correctement donné les droits en lecture seul sur la table, il ne doit rien pouvoir faire d'autre

Tu as vérifié dans le centre de contrôle ?
Il ne serait pas défini comme admin par hazard ?

[Luc Orient]

Oui un privilège comme SYSADM ou DBADM ...

[CyBeRoN]

Non, en fait l'utilisateur en question était DBADM hier matin mais je lui ai enlevé les droit. Il n'a jamais été SYSADM, SYSCTRL ou SYSMAINT.
Il est par contre administrateur au niveau WIN NT sur le serveur, mais je suppose que ça n'a rien à voir... Enfin, je vais quand même essayer

[domBLB]

regarde aussi au niveau du groupe PUBLIC si il n'y aurait pas les droits sur ces tables, dans ce cas il faudrait les revoker.

[ALHER]

DBADM
Revokes the DBADM authority.
DBADM authority cannot be revoked from PUBLIC (because it cannot be granted to PUBLIC).

CAUTION:
Revoking DBADM authority does not automatically revoke any privileges that were held by the authorization-name on objects in the database, nor does it revoke any of the other database authorities that were implicitly and automatically granted when DBADM authority was originally granted.
LOAD

Petite remarque qui a son importance dans ton cas, ton utilisateur n'est plus ADMIN mais il a encore plein de droits sur ta DB.

Il te faut donc enlever ses droits sur les autres objets DB2 pour qu'il redevienne qu'un simple quidam avec des accès contrôlés.

[CyBeRoN]

Pour un peu plus de clarté, voici la configuration actuelle :

Au niveau de la DB :




Au niveau de la table :



L'utilisateur PCCK parviens néanmoins à insérer, supprimer et mettre à jour cette table...

[Luc Orient]

Et quels droits a le user PCCK ?

[ALHER]

Les droits du DBADM autorisent implicitement la manipulation des data dans les tables, donc outrepassent les droits donnés uniquement sur les tables.

Soit, tu vire les droits DBADM et tu donne les accès selectifs sur chacune des tables (attention à ma remarque précedente conncernant le retrait des droits DBADM!) et dans ce cas PCCK ne pourrait pas lancer les utilitaires DB2 autorisés par les droits DBADM.

Soit tu transfère cet utilisateur dans un groupe avec des droits SYSCTRL, où il pourra executer certain utilitaires de maintenance, mais n'aura plus accès au data implicitement.
Dans ce cas, il pourrait même faire plus qu'un DBADM dans l'administration de la DB, mais n'aura que des droits reduits sur les data.
Le paradoxe de SYSCTRL, c'est qu'il peux faire des BACKUP. Donc aussi restorer les data ailleurs.

[CyBeRoN]

Envoyé par ALHER

Les droits du DBADM autorisent implicitement la manipulation des data dans les tables, donc outrepassent les droits donnés uniquement sur les tables.

Soit, tu vire les droits DBADM et tu donne les accès selectifs sur chacune des tables (attention à ma remarque précedente conncernant le retrait des droits DBADM!) et dans ce cas PCCK ne pourrait pas lancer les utilitaires DB2 autorisés par les droits DBADM.

Soit tu transfère cet utilisateur dans un groupe avec des droits SYSCTRL, où il pourra executer certain utilitaires de maintenance, mais n'aura plus accès au data implicitement.
Dans ce cas, il pourrait même faire plus qu'un DBADM dans l'administration de la DB, mais n'aura que des droits reduits sur les data.
Le paradoxe de SYSCTRL, c'est qu'il peux faire des BACKUP. Donc aussi restorer les data ailleurs.

Beh en fait, l'utilisateur PCCK n'est plus DBADM, je lui ai retiré ces droits.
Il devrait être considéré comme un utilisateur normal et donc respecté les droits sur la table PLC_CONFIG. Ce qu'il ne fait pas car il peut faire ce qu'il veut sur cette table (et sur les autres d'ailleurs) comme si il était toujours DBADM...

[ALHER]

Vérifie dans la table SYSIBM.SYSTABAUTH, il y a peut-être encore des droits d'accès pour PCCK qui ne devraient plus exister.
Dans ce cas, une commande REVOKE devrait pouvoir les supprimer.

[CyBeRoN]

------------------------------------- Command Entered -------------------------------------
revoke dbadm on database from user PCCK ;
---------------------------------------------------------------------------------------------------------
DB21034E The command was processed as an SQL statement because it was not a

valid Command Line Processor command. During SQL processing it returned:

SQL0556N An attempt to revoke a privilege from "PCCK" was denied because

"PCCK" does not hold this privilege. SQLSTATE=42504

Je n'ai rien trouvé d'anormal dans la table mentionnée...
Bouhhh

[CyBeRoN]

J'ai enfin trouvé un début de solution !
Il s'avère que le problème vient du fait que l'utilisateur PCCK soit administrateur au niveau de WIN NT.
J'ai mis l'utilisateur dans un groupe USELECT qui n'a aucun droit sur la DB (même pas CONNECT).
PCCK a pu se connecter et effectuer tout ce qu'il veut au niveau de la DB.
J'ai mis un autre utilisateur USERTEST dans le même groupe USELECT et là, pas moyen de se connecter à la DB.
Je donne le droit CONNECT au groupe USELECT, je me connecte avec USERTEST, j'esasie d'insérer ou de deleter dans ma table PLC_CONFIG, et là bingo, je n'ai pas les privilèges requis !

Donc ma question est : "Est-il possible de faire en sorte que DB2 ne tienne en compte que les droits décrits dans DB2 et non au niveau de WIN NT ?"

Car dans ce cas, à quoi bon définir des groupes SYSADM, SYSMAINT et SYSCTRL ?

Serait-ce dû au paramètre de l'instance AUTHENTICATION ?
Celui-ci étant actuellement défini sur SERVER. Serait-il judicieux de le passer sur CLIENT et quelles en seraient les conséquences ?

Merci d'avance !

[ALHER]

Salut,

Vérifie les droits de PCCK dans toutes les table SYSIBM.SYSxxxAUTH (en particulier la SYSDBAUTH).

Serait-ce dû au paramètre de l'instance AUTHENTICATION ?
Celui-ci étant actuellement défini sur SERVER. Serait-il judicieux de le passer sur CLIENT et quelles en seraient les conséquences ?

Pour repondre à ta question, L'interêt que PCCK soit dans le groupe ADMIN reside dans le fait qu'il doit pouvoir créer des directory pour les DB. Cela n'a rien a voir avec l'authentification.

Si tu passe en mode "Client", cela veux dire que l'authentification va se faire sur la machine qui se connecte et non plus sur le serveur DB. tu risque de perdre le controle des accès par le nombre de machines client. Je ne pense pas que ce soit une bonne idée.

[CyBeRoN]

Merci pour ces réponses !

Mais comment expliques-tu que le simple fait de passer un USER dans le groupe Administrateurs de Win NT 4.0 lui autorise toutes les manipulations au niveau des tables et ce quel que soit l'accès défini au niveau DB2 ?

Je suis persuadé que si j'enlève PCCK du groupe Administrateurs de l'OS, les droits DB2 seront respectés pour cet utilisateur.

Malheureusement, je ne peux pas me permettre de le faire de suite car c'est le USER utilisé en production actuellement....

[ALHER]

Bizarre en effet,

Malheureusement, je n'ai plus d'environement DB2 sous NT 4.0. Je n'ai donc plus l'occasion de faire un essai.
Si je trouve des infos, je te le ferai parvenir.

[CyBeRoN]

Un grand merci en tous cas pour ton aide