Discussion :

[giova_fr]

* Bonjour, *

Demain je passe aux choses sérieuses. J'ai fini d'implémenter ma base de dev, et je veux la déployer en préproduction.

L'année dernière j'avais fais un projet utilisant Postgresql et bien sagement, j'avais tout mis dans des procédures stockées. Puis quand j'ai voulu gérer les droits, j'ai rencontré de gros problèmes.

Par exemple, une table Employe avec aucun droits pour l'utilisateur lambda + une procedure SelectEmploye avec un droit d'execution pour ce meme utilisateur.

Je m'attendais alors à pouvoir forcer l'utilisateur à passer par la procédure.

Seulement voila, quand la procédure faisait le Select sur Employe, elle levait une exception, disant que l'utilisateur n'a pas le droit select sur la table employe.

Pris par le temps, et compte tenu que l'appli n'était pas pour le publique, mais qu'en interne, j'ai finalement laissé tombé.

Ce coup ci, j'ai plus de temps, et j'ai vraiment envie de border un minimum les choses. Je n'ai pas trouvé de tuto clair (dommage), pourriez vous m'expliquer en quelques mots la marche à suivre?

* Merci *

[SQLpro]

D'abord la notion de droit n'existe pas en matière de SGBDR. On parle de privilège et ce n'est pas du tout la même chose.
Un droit c'est de pouvoir lire ou écrire un fichier. Dans les SGBDR c'est le moteur qui lit et écrit les fichiers, pas les utilisateurs !
Un privilège est une autorisation d'exécution d'une commande appliqué à un objet, donné à un utilisateur SQL.
Par exemple l'INSERT sur la table T_CLIENT pour l'utilisateur U_toto.
Notez que dans ce cas, l'utilisateur U_toto ne pourra pas lire la table T_CLIENT.
Les privilèges se gèrent au niveau des objets de la base (Table, vue, procédures...) mais aussi plus bas au niveau colonne.

Dans un SGBDR comme PostGreSQL, les privilèges sont "transparent" au niveau des procédures stockées. Autrement dit, les privilèges dans une procédure sont dérivées des privilèges sur les objets manipulés. Contrairement par exemple à SQL Server ou l'on peut dépersonnaliser les exécution de procédures....

Pour tuto, voir mon site aux pages suivantes : http://sqlpro.developpez.com/cours/sqlaz/dcl/
mais aussi mon livrer, plus complet sur ce sujet (un chapitre).

A +

[giova_fr]

Merci pour la réponse.

Comme la procédure hérite des privileges de la table concernée, cela veut il dire que je dois faire un grant puis revoke à l'interrieur de ma procédure?

[estofilo]

Ce coup ci, j'ai plus de temps, et j'ai vraiment envie de border un minimum les choses. Je n'ai pas trouvé de tuto clair (domage), pourriez vous m'expliquer en quelques mots la marche à suivre?

Une fonction peut avoir soit les droits de l'utilisateur qui l'appelle (=SECURITY INVOKER), c'est le cas par défaut, soit les droits de l'utilisateur qui a créé la fonction (=SECURITY DEFINER).
C'est une option de la commande CREATE FUNCTION.
Le principe d'interdire l'insert sauf s'il est fait via une fonction nécessite l'emploi de SECURITY DEFINER.

[giova_fr]

Ca a l'air parfait ca ! merci je vais regarder ca...

Par curiosité, est ce une pratique courante avec postgresql pour attendre ce but (forcer l'utilisation de procédures)?

[SQLpro]

C'est une pratique courant et intelligente pour tous les SGBDR !!!! que d'utiliser systématiquement des vues et des procédures stockées et non d'attaquer directement les tables.

E, principe on ne devrait jamais accéder directement aux tables !

A +