Rebonjour,
je viens de me rendre compte qu'une erreur dans le RAISE NOTICE est à
l'origine du dysfonctionnement. La véritable instruction de ma procédure
était RAISE Notice 'Creation du compte', req dans laquel il manque un %
et qui générait une erreur entraînant le ROLLBACK - cette erreur étant à
la fin du code je me suis fait leurrer en testant des doubles création /
suppression, le problème étant plus loin. Je suis désolé d'avoir soumis
un faux problème mais au moins ça permettra peut-être à certains de
traiter ces notions de délégation de gestion des comptes en cas
d'hébergement.
Bonne journée.
Alain.
-----RAPPEL de la demande ------------------------------------------
Le 09/02/2012 10:39, Alain Benard a écrit :
> Bonjour,
> hébergeant une base de donnée de collègues à qui je ne souhaite pas
> confier trop de privilèges sans toutefois vouloir gérer complétement
> leur population d'utilisateurs voici mes tentatives :
> Dans les 2 scénarios ci-après je créé leur base avec 3 groupes (1 pour
> l'administration de la structure, 1 pour la modification des données,
> 1 pour la consultation)
>
> 1. premier scénario : je créé un ou plusieurs compte avec l'option
> CREATEROLE dans la commande CREATE ROLE. Ce ou ces comptes peuvent
> bien créer d'autres rôles et les inscrire dans les groupes ou
> rôles adéquats mais disposent cependant de trop de droits
> (suppression ou modification de n'importe quel rôle - inscription
> de rôles dans des groupes donnant accès à d'autres bases de
> données ...). La solution n'est donc pas dans ce scénario (sauf si
> j'ai loupé quelque chose ???).
> 2. second scénario : j'essaie de créer une procédure stockée qui
> s'exécute avec les droits du definer (un admin par exemple) et qui
> crée le compte utilisateur en l'ajoutant dans un groupe fixé à
> l'avance. Par exemple une fonction ajout_lecteur(nomlecteur) qui
> crée le rôle nomlecteur et l'inscrit dans le groupe habilité à
> consulter la base en question. En dehors du contexte d'exécution
> de la procédure stockée le compte n'existe pas, c'est à dire qu'il
> n'y a pas persistance de la création du compte : pour affirmer ça
> j'ai tenté de supprimer le compte après sa création dans la proc
> stockée (2 lignes commentées avec DROP ROLE) et même de le créer
> une seconde fois avec un message d'erreur obtenu précisant qu'il
> existe déjà. Est-ce que des mécanismes internes interdisent à
> postgres de faire ça auquel cas il faudrait que les possibilités
> d’administration soient revues, ou bien je fais une erreur de mon
> analyse?? Ci-dessous le code plpgsql.
>
> CREATE OR REPLACE FUNCTION public.creer_lecteur ( compte text)
> RETURNS pg_catalog.void AS
> $body$
> DECLARE
>
> --declaration des variables de traitements
>
> req varchar(4000);
>
> BEGIN
> req := 'CREATE ROLE ' || compte || ' LOGIN PASSWORD
> ''password'' IN ROLE bdd_lecture;';
> EXECUTE req;
>
> -- req := 'DROP ROLE ' || compte || ';';
> -- EXECUTE req;
>
> RAISE NOTICE 'Creation du compte';
>
> EXCEPTION
> WHEN OTHERS THEN
> raise notice '% %', sqlstate, sqlerrm;
>
> RETURN;
> END;
>
> $body$
> LANGUAGE 'plpgsql'
> IMMUTABLE
> CALLED ON NULL INPUT
> SECURITY DEFINER
> COST 100;
>
> Merci par avance.
> Alain Benard
>
>
>