Discussion :

[olivierB75]

Bonjour,

Je rencontre un pbm de cohérence d'administration des droits sur les objets sql server 2000.

J'ai une table test & un utilisateur user1, à ce user1 je lui interdis (DENY UPDATE ON test TO user1)d'effectuer des MAJ sur la table test

en conséquent, lorsque j'execute un update sur la table test via le user user1, j'obtiens le message suivant :

"Autorisation UPDATE refusée sur l'objet test, base de données 'BdADM', propriétaire 'dbo'."

Pas d'incohérence, la MAJ est refusée ..

En revanche, lorsque j'inscris cette instruction de MAJ au sein d'une procédure stockée SP_test & que j'exécute cette SP_test via le user1, l'instruction de MAJ est acceptée, or selon moi elle devrait être refusée à l'instar du premier cas (MAJ de la table test hors procedure stockée)

Merci pour vos lumières..

Cordialement...

[mikedavem]

Bonjour,

Vous êtes dans un cas de "ownership chaining".

En supposant que vous êtes le propriétaire des 2 objets (table et procédure stockée) et que vous avez donner le droit d'exécution sur la procédure stockée alors ce comportement est tout à fait normal. En effet, vous avez le déroulement suivant :

user1 --> exécution procédure --> comparaison des propriétaires entre l'objet appelant et l'objet appelé --> Si les propriétaires sont les mêmes alors les permissions sur l'objet appelé ne sont pas vérifiés

Donc dans votre cas la permission DENY ne sera pas vérifiée. Ce comportement est déroutant au début mais logique. Vous interdisez une mise à jour directe sur votre table pour un utilisateur donné mais cela ne veut pas dire qu'il ne pourra pas le faire à l'aide d'une procédure stockée dans laquelle vous allez contrôler le processus.

++

[SQLpro]

Et oui, une procédure s'apparente à la programmation objet dans lequel l'intérieur est une boite noire...

C'est d'ailleurs tout l'intéret !

A +

[olivierB75]

Bonjour,

Vous êtes dans un cas de "ownership chaining".

En supposant que vous êtes le propriétaire des 2 objets (table et procédure stockée) et que vous avez donner le droit d'exécution sur la procédure stockée alors ce comportement est tout à fait normal. En effet, vous avez le déroulement suivant :

user1 --> exécution procédure --> comparaison des propriétaires entre l'objet appelant et l'objet appelé --> Si les propriétaires sont les mêmes alors les permissions sur l'objet appelé ne sont pas vérifiés

Donc dans votre cas la permission DENY ne sera pas vérifiée. Ce comportement est déroutant au début mais logique. Vous interdisez une mise à jour directe sur votre table pour un utilisateur donné mais cela ne veut pas dire qu'il ne pourra pas le faire à l'aide d'une procédure stockée dans laquelle vous allez contrôler le processus.

++

Merci pour votre réponse particulièrement instructif..

En résumé pour une stratégie maitrisé des droits d'accès sur les objets sql server, il convient donc d'assigner un propriétaire différent par type d'objet sql server (table, SP,udf..etc...)...?

[SQLpro]

non... ce n'est pas le but, car vous allez vous retrouver avec une multitude d'utilisateurs qui ne pourrons plus être supprimés....

Pour comprendre le modèle de sécurité, et surtout comment s'en servir, il vous faudrait une solide formation...
Je pense que la façon dont vous l'avez conçue n'est pas du tout la bonne.
Néanmoins vous pouvez peut être vous en sortir en ajoutant dans la procédure un EXECUTE AS....

A +