Précédent   Forum des professionnels en informatique > Bases de données > MS SQL-Server > Administration
Administration Forum d'entraide sur l'administration du dataserver, via SSM ou ligne de commande, les tables système, ...
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 14/12/2011, 14h40   #1
Invité de passage
 
Homme
Inscription : décembre 2011
Messages : 2
Détails du profil
Informations personnelles :
Sexe : Homme
Localisation : France

Informations forums :
Inscription : décembre 2011
Messages : 2
Points : 0
Points : 0
Par défaut coherence administration des droits entre objets base de données

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...
olivierB75 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/12/2011, 15h11   #2
Responsable SQL Server

 
Avatar de mikedavem
 
Homme David BARBARIN
Expert SQL Server
Inscription : août 2005
Messages : 3 725
Détails du profil
Informations personnelles :
Nom : Homme David BARBARIN
Localisation : France, Haute Savoie (Rhône Alpes)

Informations professionnelles :
Activité : Expert SQL Server
Secteur : Conseil

Informations forums :
Inscription : août 2005
Messages : 3 725
Points : 6 849
Points : 6 849
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.

++
mikedavem est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/12/2011, 16h11   #3
Rédacteur/Modérateur

 
Avatar de SQLpro
 
Homme Frédéric BROUARD
Expert SGBDR & SQL
Inscription : mai 2002
Messages : 10 959
Détails du profil
Informations personnelles :
Nom : Homme Frédéric BROUARD
Localisation : France

Informations professionnelles :
Activité : Expert SGBDR & SQL
Secteur : Conseil

Informations forums :
Inscription : mai 2002
Messages : 10 959
Points : 17 791
Points : 17 791
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 +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
SQLpro est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/12/2011, 18h11   #4
Invité de passage
 
Homme
Inscription : décembre 2011
Messages : 2
Détails du profil
Informations personnelles :
Sexe : Homme
Localisation : France

Informations forums :
Inscription : décembre 2011
Messages : 2
Points : 0
Points : 0
Citation:
Envoyé par mikedavem Voir le message
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...)...?
olivierB75 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 14/12/2011, 18h15   #5
Rédacteur/Modérateur

 
Avatar de SQLpro
 
Homme Frédéric BROUARD
Expert SGBDR & SQL
Inscription : mai 2002
Messages : 10 959
Détails du profil
Informations personnelles :
Nom : Homme Frédéric BROUARD
Localisation : France

Informations professionnelles :
Activité : Expert SGBDR & SQL
Secteur : Conseil

Informations forums :
Inscription : mai 2002
Messages : 10 959
Points : 17 791
Points : 17 791
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 +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
SQLpro est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 04h51.


 
 
 
 
Partenaires

Hébergement Web