Forum Programmation.SQL PostgreSQL : droits des utilisateurs.

Posté par  .
Étiquettes : aucune
0
2
mar.
2007
Bonjour à tous ...

Bon, c'est une question tellement bête que j'ai honte de la poser, mais je n'ai pas encore réussi à m'en sortir :je n'arrive pas à empêcher un utilisateur donné de créer des tables dans une base qui n'est pas la sienne.

Il va sans dire que j'ai essayé REVOKE dans tous les sens, sans beaucoup de succès (REVOKE CREATE et REVOKE ALL PRIVILEGES sur DATABASE xxx, TABLESPACE xxx , sans succès).

Je suis tombé sur ce commentaire :

http://archives.postgresql.org/pgsql-admin/2000-06/msg00133.(...)

Mais il date du Juin 2000, il y a presque sept ans. J'imagine que la situation a évolué depuis, non ? Pourtant tous mes utilisateurs sont identifiés correctement à l'entrée (et doivent le faire, comprendre que je n'ai pas laissé "trust" dans pg_hba.conf). Je gère différents tablespaces, j'ai réglé les variables correctement (il me semble) pour tous les comptes, notamment search_path pour les schémas, etc. et pour l'instant, aucun utilisateur ne fait partie d'un ROLE donné.

Actuellement, je ne travaille qu'au travers de psql.

Qu'est-ce que j'ai oublié ?


Merci à tous.

  • # pg_hba.conf

    Posté par  . Évalué à 4.

    pg_hba.conf, c'est pour l'authentification, établir l'identité des utilisateurs. Si tu n'as pas de trust mais des méthodes sures (md5, ident sameuser, etc) ça empêche n'importe qui de se faire passer pour quelqu'un d'autre.

    Maintenant, si tu veux restreindre l'accès à un seul utilisateur, tu peux le faire soit dans hba soit en grant/revoke connect.
    Sinon, GRANT/REVOKE sur ce qu'il faut.

    Mais juste comme ça, tes gars, ils sont pas superuser par hasard ?

    • [^] # Re: pg_hba.conf

      Posté par  . Évalué à 2.

      Bonsoir,

      Maintenant, si tu veux restreindre l'accès à un seul utilisateur, tu peux le faire soit dans hba soit en grant/revoke connect.
      Sinon, GRANT/REVOKE sur ce qu'il faut.


      Mais ça, comme précisé, j'ai déjà essayé.

      Mais juste comme ça, tes gars, ils sont pas superuser par hasard ?


      Hélas non ! Je savais bien que j'avais oublié de préciser quelque chose d'ailleurs :-) Rien de tout ça. Mes users sont très ordinaires. Un \du+ et un SELECT * FROM pg_role; confirment ce fait.

      Pas non plus de role par défaut, ni de variables précises. Je ne comprend pas.

      Personne à part moi ne rencontre ce problème ?

      • [^] # **** Résolu ****

        Posté par  . Évalué à 4.

        Bon, ok.

        Je suis tombé sur une entrée de forum dans laquelle quelqu'un explique que GRANT/REVOKE CREATE ON DATABASE ... ne concerne que le droit de créer des schémas.

        Il faut donc ensuite appliquer des GRANT/REVOKE sur les différents schémas éventuels, à commencer par "public".

        C'est bon à savoir, et ça gagnerait à être développé un peu plus explicitement dans le manuel.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.