Vous n'êtes pas identifié(e).
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
oops: ton link est mort!
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;
??
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 
>> Concernant le créateur des rôles, cette information n'est pas conservée.
Ok, j'ai ma réponse: ça confirme keskejpensè; il *faut* que je double la manip de création avec l'inclusion du nom de groupe dans une table séparée.
Merci
Pour l'universalité des groups/users dans un même cluster PG, je l'ai bien compris puisque les docs sont claires et que je les "vois" à partir de ma base de test.
Je vais essayer d'être plus clair: Base = DB1 - Owner = ZEBOSS - Groupe (vide pour l'instant) créé par ZEBOSS = GRP1
SELECT* FROM pg_auth_members; => Table vide
CREATE GROUP grp1;
SELECT* FROM pg_auth_members; => Table toujours vide >>> ICI se tient mon PB: comment récupérer seulement les noms/oids des groupes créés par ZEBOSS?
CREATE USER usr1 IN GROUP grp1;
SELECT* FROM pg_auth_members; => 162111 / 162113 / 156540 / F <=> Là c'est bon, MAIS il a fallu ajouter un user dans le groupe pour qu'il devienne "visible"
PB: Comment récupérer tous les groupes (VIDES et NON-VIDES [mais là, je sais faire]), créés par ZEBOSS ?
Jiff
PS: Me dit pas vous, j'ai l'impression d'être un vieux.
PS2: J'ai malheureusement l'impression qu'il va me falloir mettre ces groupes vides dans une table de référence pour savoir qu'il appartiennent à ZEBOSS!?
Salut,
Je suis sur une petite appli qui doit gérer les droits PG pour une plus grosse et je bloque sur cette correspondance.
Le propriétaire de la base est aussi SU (pour accès aux tables système), et pour test, j'ai créé un groupe 'groupe01' & un user 'user01'.
SELECT * FROM pg_group me renvoie bien la correspondance user01-groupe01, par contre, je n'arrive pas à trouver ce qu'il me faut pour la correspondance propriétaire-group01 (afin de séparer les groupes de cette base de ceux des autres bases.)
SELECT * FROM pg_auth_members ne renvoie un row QUE si un user est déclaré dans le groupe (et là, ça va, puisque je retrouve mon grantor.)
Connaîtriez-vous une solution à mon casse-ctête? (sinon, la seule solution que je vois serait de créer un "dummy_user", appartenant à chaque groupe et n'ayant pas les droits de connexion, mais c'est plutôt bancal et potentiellement dangereux en cas d'oubli.)
Effectivement, vu le déroulement des opérations, c'est parfaitement logique que le savepoint soit global et propagé.
Ok merci
Si je vous comprends bien tous les 2, l'appel d'une procédure stockée déclenche donc automatiquement une transaction, ce qui fait qu'il ne faut surtout pas en lancer une avant d'appeler la proc.
Je suppose logiquement qu'en cas de pépin, le rollback sera automatique (voire partiel si je passe par des savepoints), et que la seule trace apparente qu'il laissera au client sera le retour d'un message d'erreur indiquant la nature du pépin et le rollback?
Salut forumateurs,
J'ai beau creuser la doc de PG 8.4, je ne retrouve pas la page expliquant qu'on ne peut pas intégrer une transaction dans une procédure stockée.
Ai-je loupé la page en question, ou bien cette limitation a-t'elle été levée?
Oui, c'est l'explication que j'ai fini par trouver.
Par opposition à la vue, ça va m'obliger à tester tous les droits possibles sur une table pour un user, mais finalement ça n'est pas plus mal puisqu'il faut bien occulter les items des menus auxquels il n'a pas droit (sans compter la construction correcte des requêtes en lecture).
De plus, juste avec les droits tables/champs, je devrais normalement éviter ce genre d'effet de bord.
oops, je n'avais pas vu l'arrivée de la réponse.
Une fois de plus: merci Marc! (et en plus, cela m'arrange drôlement puisque je développe en parallèle le gestionnaire des droits (tables, champs, procédures...) qui va me permettre de faire d'une pierre deux coups)
flute, j'ai oublié un point important: les vues se justifient-elles toujours, vu que c'est la version 8.4 de PG que j'utilise ? (s/s entendu: est-ce que les droits sur colonnes ne seraient pas nécessaires et suffisants?)
Salut,
Après avoir lu quelques tonnes de docs, j'en suis venu à la conclusion que mon appli ne devait avoir d'accès en lecture qu'à travers des vues.
Cependant certains aspects restent obscurs: notamment comment faire pour que X voit les champs a,b,c mais que Y ne voit que a,c, le tout sur une même vue (enfin si cela est possible).
Un rapide test m'a démontré que les droits SELECT (CHAMPS) définis user par user sont outrepassés par les droits SELECT accordés sur une même vue (en l'occurence, X avait tous les droits SELECT (CHAMPS) sur a,b & c, Y seulement sur b, mais la vue était sur a & c et Y voyait quand même les champs interdits).
La conclusion "logique" de ce chtit test, c'est qu'il me faudrait une vue par type d'utilisateur, le PB, c'est que dans ce cas, cela va vite virer à l'usine à gaz.
Donc ma question est: y'a-t'il une possibilité de faire ce que je veux avec seulement une seule vue, ou si cela n'est pas possible, comment puis-je générer automatiquement les vues nécessaires?
Jiff
(jsais pas si j'ai réussi à être très clair sur ce coup-là?)
oops: effectivement: PlpgSQL
Ok, merci pour ta prompte réponse (je pensais que c'était interprété à chaque appel)
Ca m'éviteras surtout d'avoir 2 versions: la commentée et la non-commentée.
Nickel ce forum: à chaque fois la réponse juste, et en très peu de temps 
Salut forumeurs,
j'ai remarqué que les procédures étaient stockées dans PG avec leurs commentaires.
Si les lignes de commentaires sont très nombreuses, cela peut-il avoir une réelle incidence négative sur le temps d'exécution?
(je pense notamment à des procs appelées très souvent et très largement (>=10E6))
Merci
Jiff
Merci Marc, c'est bien ce que je recherchais.
Pour le pg_dump, ça n'est pas possible: le but étant de récupérer les droits au démarrage de l'appli
afin de la reconfigurer pour que l'utilisateur ne voit plus que ce à quoi il a droit (plus exactement: que
les formulaires soient en adéquation avec les droits, puisque de toute façon, il ne pourra jamais
voir/modifier/... les données sur lesquelles il n'a pas de droits.)
Salut,
Je dois faire un contrôleur/dispatcher de droits pour Pg 8.4 descendant jusqu'à la colonne.
* Y'a-t'il une possibilité de récupérer les droits sur les tables autre qu'en utilisant un parser sur pg_roles.rolconfig[] ?
* Comment puis-je récupérer les droits par colonne pour chaque table ?
Le but étant un affichage en arborescence rôle table> user & rôle table/colonne > user (les modifications étant faites par de classiques GRANT/REVOKE.)
Par ailleurs que me conseilleriez-vous au niveau des rôles "base": un seul (gros) rôle contenant toutes les autorisations dont le user hérite, ou bien une multitude de rôles (disont un par table, incluant vues, trigers... afférents) dont un autre rôle hérite; le user héritant du dernier ?
Merci d'avance.
