Vous n'êtes pas identifié(e).
Pages : 1
Merci dverite pour la piste de la fonction depossession().
Ce qui me gène précisément c'est de devoir donner tous les droits et tous les droits admin sur tous les objets sql de la base de données y compris celle-ci à un développeur que l'on intégrerait dans le groupe admin .
Alors que le groupe admin donne juste le droit de créer des objets sql au nom du propriétaire de la base de données.
par "droits full" sur la db je veux dire avoir tous les droits sur les objets appartenant à cette db ( schemas, tables, fonctions, types, séquences, ...)
Ce que je voudrais arriver à faire c'est :
- avoir un groupe "admin" qui permettrait de créer et supprimer des objets sql (tables, fonctions, types, séquences,operateurs, vues, seulement cela),
- et que le owner des objet créés par le groupe admin soit le propriétaire de la db.
- je ne voudrais pas que le groupe admin aie d'autres droits ( par exemple, ne pas pouvoir donner des droits à des utilisateurs).
J'avais indiqué au départ que u1 appartenait à monprojet_admin :
...
- j'ai le groupe admin de la db : "monprojet_admin"
- j'ai un utilisateur final de la db "monprojet" : "u1". "u1" appartient au groupe admin de la db
...
C'est vraiment dommage que PostgreSQL gère cela de cette façon.
En résumé, pour détruire ou créer des objets il faut être membre direct/indirect du propriétaire des objets ou du propriétaire de la db du propriétaire du schéma ou du propriétaire de la db...
Merci pour ta réponse Gleu,
Cependant si je comprends bien la clause OWNER implique que celui qui l'utilise soit membre direct/indirect.
Donc, dans mon cas "monprojet_admin" sera membre direct de "monprojet_owner" et "u1" sera membre indirect de "monprojet_owner"
Ce qui implique que si "u1" exécute 'set role monprojet_admin' puis 'set role monprojet_owner', "u1" aura les droits full sur la db.
Hors, je n'ai pas envie que u1 puisse octroyer des droits à d'autres utilisateur.
Bonjour à tous,
Je suis face à un problème que je ne parviens pas à résoudre :
voici la situation
- j'ai une db : "monprojet"
- j'ai le propriétaire de la db : "monprojet_owner"
- j'ai le groupe admin de la db : "monprojet_admin"
- j'ai un utilisateur final de la db "monprojet" : "u1". "u1" appartient au groupe admin de la db
- j'ai un autre utilisateur : "u2"
Voici ce à quoi je voudrais arriver:
- Je vourdrais que le owner de la db ne puisse pas se connecter à la db ( ca c'est ok).
- je voudrais que l'utilisateur "u2" ne puisse rien faire à part se connecter à la db et et effectuer des select, update delete dans la db ( c'est ok également).
Ce qui me pose problème :
- je voudrais que le groupe admin de la db puisse supprimer des objets sql (schemas, tables, fonctions, types, séquence, etc) , créer des objets sql mais que le propriétaire de ces nouveaux objets sql soit le propriétaire de la db.
L'idéal serait que l'utilisateur "u1" (qui fait partie du groupe admin de la db), lorsqu'il crée un objet sql dans la db :
- Il n'aie pas besoin de faire un set role.
- que tous les objets créés soit au nom du propriétaire de la db.
Est ce possible de suivre ce schéma?
Peut-etre existe-t-il une best practice pour la gestion des utilisateurs?
Merci pour vos réponses.
Merci pour ta réponse gleu !
une idée concernant cette question :
- Dans quel cas pourrais-je avoir un oid impair dans pg_enum (car je pense que les énum sont tous triés)?
Bonjour à tous,
J'ai besoin de vos connaissances concernant une problématique qui permet de corrompre une table :
- la suppression manuelle d'une valeur d'énum dans le catalogue pg_enum avec une requête de cette sorte :
delete from pg_enum where enumtypid = 1135484 and enumsortorder = 3;
select * from mytable;
ERROR: invalid internal value for enum: 1135490Ce que je sais :
- Il faut absoluement éviter de modifier manuellement un cataolgue
- Les colonnes d'un type enum stocke en réalité l'oid de du record associé du catalogue pg_énum ce qui fait que lors d'une supression d'une valeur d'énum encore utilisé on obtient une erreur et lorsque on rajoute la valeur d'énum dans pg_enum on obtient également une erreur.
- Lorsque oid est pair les valeurs sont garanties triées.
- Lorsque oid est impair les valeurs ne sont pas garanties triées.
Ce que je voudrais savoir :
- Dans quel cas pourrais-je avoir un oid impair dans pg_enum (car je pense que les énum sont tous triés)?
- Qu'est ce qu'il y a lieu de faire pour récupérer ma table corrompue par une suppression manuelle (delete) dans pg_enum?
- un autre insert quelconque?
- modification des fichiers binaires des données de la table?
- autre chose?
Merci pour vos réponses !
Bon à tous,
Je ne comprends pas (pas d'un point de vue traduction) le 2e paragraphe du titre "Creating Accounts and Roles" de cette page web.
Voici l'extrait :
Grant database object privileges to users or application accounts through the use of roles. Create a set of roles appropriate for an application. For simplicity create at least two roles, one to use for read/write privileges for the application and one for query privileges. As database objects are created for the application perform the appropriate grants to the roles.
Est ce que quelqu’un est capable de réexpliquer ce paragraphe?
Merci et bonne journée.
Merci à vous pour vos réponses et informations,
Dès que le serveur sera en production et en cas de souci identifié je rouvrirai le poste.
Bonne journée
Je n'ai pas encore le serveur en production...
La version PostgreSQL serait la 9.5
mais dans un premier temps voici le configsuration que je compte mettre en place :
wal_buffers = -1 (basé sur shared buffer)
checkpoint_completion_target = 0.9
checkpoint_timeout = 15 min
Pour min_wal_size et max_wal_size, je compte laisser par défaut dans un premier et me baser sur les calculs trouvés sur ce site
Peut-être qu'il sera difficile de répondre à ma question sans serveur en production...
Merci
Bonjour à tous,
Je souhaiterais connaître la "formule" pour configurer correctement les valeurs de vm.dirty_background_bytes et vm.dirty_bytes.
Ou du moins, m'indiquer dans quel cas doit-on l'augmenter ou la diminuer.
Si je ne me trompe pas, ces deux paramètres interviennent dans le "lissage" des checkpoints (checkpoint_completion_target)
De quoi cela dépend-il ? J'imagine que cela dépend des disques, du RAID, ...
Le serveur PostgreSQL serait un serveur dédié.
Merci !
Pages : 1