Vous n'êtes pas identifié(e).
Pages : 1
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 
Hors ligne
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.
Hors ligne
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;
??
Hors ligne
oops: ton link est mort!
Hors ligne
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.
Hors ligne
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
Hors ligne
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 ?
Hors ligne
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)
Hors ligne
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.
Hors ligne
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'?
Hors ligne
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.
Hors ligne
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é.)
Hors ligne
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?
Hors ligne
Un REVOKE ALL doit suffire.
Guillaume.
Hors ligne
Pages : 1