Forums PostgreSQL.fr

Jiff

Membre

Soucis de droits

Salut,

Quelqu'un aurait-il la gentillesse de me brieffer sur les priorités des droits PG (ou pointer vers une doc, je n'en ai pas trouvé)?

Ex: Dans le schéma SCH, j'ai une proc PROC (toute simple: pas de parms, retourne un integer), le owner (également SU) est celui qui donne les droits.

RIEN   =>   test n'a pas l'accès à SCH (normal)

GRANT EXECUTE ON FUNCTION sch.proc TO USER test   =>   test n'a pas accès à SCH (et donc pas à PROC) (normal ?)

GRANT USAGE ON SCHEMA sch TO USER test   =>   test voit tout (normal), et peut exécuter PROC (semble normal, puisque précédemment autorisé)

REVOQUE EXECUTE ON FUNCTION sch.proc FROM USER test => PB: user peut toujours exécuter PROC

J'ai testé dans tous les sens, mais quelque soit la combinaison le résultat est identique; même si TEST n'a pas reçu de GRANT EXECUTE sur PROC

gleu

Administrateur

Re : Soucis de droits

Quelqu'un aurait-il la gentillesse de me brieffer sur les priorités des droits PG (ou pointer vers une doc, je n'en ai pas trouvé)?

Il y a http://blog.postgresql.fr/index.php?post/drupal/137. C'est plus de la gestion des rôles mais bon, concernant les droits, y'a vraiment pas grand chose à savoir.

GRANT EXECUTE ON FUNCTION sch.proc TO USER test   =>   test n'a pas accès à SCH (et donc pas à PROC) (normal ?)

Oui, normal. En fait, le message d'erreur est explicite: ERREUR:  droit refusé pour le schéma sch. Il faut ajouter le droit USAGE au schéma pour cet utilisateur, comme vous l'avez d'ailleurs découvert après.

GRANT USAGE ON SCHEMA sch TO USER test   =>   test voit tout (normal), et peut exécuter PROC (semble normal, puisque précédemment autorisé)

Oui et non. Oui, c'est normal qu'il puisse l'exécuter, non ce n'est pas grâce au GRANT EXECUTE. En fait, tout le monde a le droit d'utiliser la fonction tant que :
1. cette personne a le droit d'utiliser le schéma
2. ce droit n'ait pas été explicitement révoqué à PUBLIC.

PUBLIC est un espèce de groupe regroupant tous les utilisateurs existant et les futurs qui seront créés. Pour empêcher l'utilisation de la fonction par un utilisateur particulier, il faut révoquer les droits de PUBLIC et ajouter les droits aux bons utilisateurs.

revoke execute on function sch.proc() from public;

---

Guillaume.

Jiff

Membre

Re : Soucis de droits

Pourtant, à la fin de mon script d'init de la base, j'avais normalement fait cela:
REVOKE ALL ON SCHEMA public FROM public;
DROP SCHEMA public;

??

Jiff

Membre

Re : Soucis de droits

oops: ton link est mort!

gleu

Administrateur

Re : Soucis de droits

REVOKE ALL ON SCHEMA public FROM public;
DROP SCHEMA public;

Le schéma public et le méta-groupe public sont deux choses différentes. Autant il est possible de supprimer le schéma, autant le méta-groupe ne peut pas être supprimé. Et ses droits doivent être supprimés des objets pour que ces derniers puissent être finement configurés.

oops: ton link est mort!

En fait, le forum a ajouté le point final de la phrase dans le lien. Donc c'est http://blog.postgresql.fr/index.php?post/drupal/137

---

Guillaume.

Jiff

Membre

Re : Soucis de droits

Le schéma public et le méta-groupe public sont deux choses différente

Haaa, je comprends maintenant, j'étais persuadé qu'il n'existait qu'un schéma "public"

Merci

Jiff

Membre

Re : Soucis de droits

Juste une dernière question, histoire d'être absolument sur de ne faire aucune connerie: "REVOQUE ALL ON DATABASE mydb FROM public" est-il suffisant ?

Jiff

Membre

Re : Soucis de droits

Bon, je me réponds tout seul: NON!

Apparemment il faut aussi "REVOQUE ALL ON SCHEMA xxxx FROM public", ce qui n'est absolument pas logique, la DB étant censée chapeauter tout le reste (mais bon, je dois me tromper qq part)

gleu

Administrateur

Re : Soucis de droits

Les droits de la base ne sont pas identiques aux droits des autres objets, donc non, un REVOKE ALL ON DATABASE x ne supprimera pas les droits sur les autres objets. Je dirais, contrairement à vous, que c'est (trop?) logique. On supprime les droits de la base de données, point. Pas sur les objets inférieurs (schémas, tables, vues, etc).

D'ailleurs, c'est la même logique que pour les droits d'un répertoire dans un système de fichiers. En acceptant l'accès à un répertoire, vous ne donnez pas ce droit à tous les sous-répertoires de ce répertoire.

---

Guillaume.

Jiff

Membre

Re : Soucis de droits

Ok pour l'analogie avec les répertoires, c'est très parlant
Donc, si j'ai bien suivi et vu qu'il n'y-a pas propagation des droits, cela veut dire que je vais être obligé de révoquer *tous* les droits sur *tous les "objets"*;
soit: REVOQUE ALL ON (DB, TABLESPACE, LANGUAGE, SCHEMA, FUNCTION, SEQUENCE, TABLES, CHAMPS, VIEW, TRIGGER, RULE, ) FROM public ? (en ai-je oublié?)
Ou bien seulement certains REVOQUE vont-ils suffire à tous interdire au méta-user 'public'?

gleu

Administrateur

Re : Soucis de droits

CHAMPS n'existe pas, VIEW est équivalent à TABLE dans ce cadre. TRIGGER et RULE ne font pas partie des objets auxquels on peut donner des droits. Les contraintes rentrent aussi dans ce cas des objets sans droits, vu qu'ils sont là pour assurer la cohérence des données, comme les triggers et les rules.

Le REVOKE doit être fait sur chacun des objets restants.

---

Guillaume.

Jiff

Membre

Re : Soucis de droits

Merci, je vois mieux le tableau d'ensemble maintenant et j'incluerai les REVOQUE au moment de la création des objets (mais c'est galère comme fonctionnement, tout bloquer de base aurait été plus logique question sécurité.)

Jiff

Membre

Re : Soucis de droits

Une dernière pour la route: Est-ce qu'un REVOQUE ALL sur chaque objet est suffisant, ou bien faut-t'il rentrer dans le détail?

gleu

Administrateur

Re : Soucis de droits

Un REVOKE ALL doit suffire.

---

Guillaume.