L'utilisateur créé peut accéder à toutes les bases de données de PostgreSQL sans aucune subvention.

44

Il me manque quelque chose concernant la configuration de PostgreSQL. Ce que j'aimerais faire, c'est créer plusieurs bases de données et utilisateurs isolés les uns des autres, de sorte qu'un utilisateur spécifique n'ait accès qu'aux bases de données que je spécifie. Cependant, d'après ce que je peux déterminer, tout utilisateur créé a accès à toutes les bases de données sans aucune subvention spécifique.

Voici ce que je fais sur un serveur Ubuntu 12.04:

apt-get install postgresql
sudo -u postgres createuser -DRSP mike1 (Spécification du mot de passe du nouvel utilisateur)
sudo -u postgres createdb data1
psql -h localhost -U mike1 data1 (Spécification du mot de passe permettant à l'utilisateur mike1 de se connecter)

Il semble que le nouvel utilisateur "mike1" n'a aucun problème à se connecter à la base de données "data1" et à créer des tables, etc. Et cela sans exécuter aucune commande GRANT (et le propriétaire de "data1" est "postgres" car je n'ai pas spécifié propriétaire à l'étape 3). Est-ce vraiment ainsi que cela est supposé fonctionner?

Ce que j'aimerais faire, c’est accorder à mike1 un accès complet à data1, puis le répéter pour davantage d’utilisateurs et de bases de données, en veillant à ce que les utilisateurs n’aient accès qu’à une (voire à plusieurs) bases de données de mon choix.

postgresql permissions

— plaque de micro
source

1

N'oubliez pas que même si un utilisateur est limité à une base de données, il peut toujours interroger les tables globales, ce qui lui permettra de voir la liste des noms de base de données et la liste des utilisateurs.

— Kgrittn

47

Au niveau SQL, chaque utilisateur peut en effet se connecter à une base de données nouvellement créée jusqu'à ce que la commande SQL suivante soit émise:

REVOKE connect ON DATABASE database_name FROM PUBLIC;

Une fois cela fait, chaque utilisateur ou rôle qui devrait pouvoir se connecter doit se voir attribuer explicitement le privilège de connexion:

GRANT connect ON DATABASE database_name TO rolename;

Edit: Dans un scénario à plusieurs locataires, plus que le connectprivilège serait supprimé. Pour des astuces sur les locations multiples et les meilleures pratiques, consultez le wiki public de postgresql: Hébergement de bases de données partagées et gestion des droits dans PostgreSQL .

— Daniel Vérité
source

La valeur par défaut aurait dû être l'inverse. Je souhaite créer un utilisateur avec un mot de passe généré de manière aléatoire et lui accorder l'accès à une seule base de données, sachant qu'il postgrespeut accéder à toutes les bases de données.

— TheRealChx101

24

PUBLIC a accès à la base de données par défaut, mais il ne peut pas accéder aux données. Vous pouvez annuler le public:

REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;

Si vous souhaitez ce paramètre pour toutes les futures bases de données, révoquez CONNECT sur la base de données template1 (la base de données template par défaut pour la création d'une nouvelle base de données):

REVOKE CONNECT ON DATABASE template1 FROM PUBLIC;

— Frank Heikens
source

Je vois. Maintenant, cela a plus de sens. Je suppose que je ne devrais pas venir ici en tant que nouveau venu dans PostgreSQL et contester que PUBLIC ne devrait peut-être pas avoir le privilège CONNECT sur template1 par défaut :) Mais je vois aussi que les données n'ont jamais été compromises. Merci!

— Microcassette

1

En tant que nouveau venu, vous êtes le bienvenu, mais aussi pour contester les paramètres. Tout le monde peut apprendre de ça!

— Frank Heikens

1

En réalité, ce privilège CONNECT n'est pas transmis du modèle à la nouvelle base de données. Par conséquent, sa révocation sur le modèle1 n'a pas l'effet mentionné.

— Daniel Vérité

2

@ DanielVérité je vois. Donc, je suppose que la solution consiste à toujours se souvenir de REVOKE CONNECT lors de la création d'une nouvelle base de données. Est-ce vraiment la façon dont les administrateurs de PostgreSQL le font, ou ne devrais-je pas m'en soucier autant, car les données ne sont de toute façon pas accessibles? Néanmoins, je pense qu'une liste de tables peut donner des informations inutiles pour de futures attaques, ne serait-ce que entre des utilisateurs déjà autorisés dans un environnement multi-locataire. Aussi: je viens de me rendre compte que public peut aussi créer ses propres tables dans n'importe quelle base de données qui n'a pas été REVOKE CONNECT. Ça fait un peu bizarre d'avoir par défaut, je dois dire.

— Microcassette

1

Oui. J'ajoute des liens connexes à ma réponse, vous voudrez peut-être lire quelques autres documents à ce sujet.

— Daniel Vérité

4

Outre la révocation par défaut des privilèges de connexion à PUBLIC et leur attribution comme vous le souhaitez, vous pouvez également contrôler l'accès via le fichier pg_hba.conf.

Vous pouvez trouver où le fichier est stocké avec:

SHOW hba_file;

Si vous choisissez d'utiliser ce mécanisme, il existe des commentaires intégrés qui peuvent suffire à vous aider à démarrer. Les docs sont ici:

http://www.postgresql.org/docs/current/interactive/auth-pg-hba-conf.html

— Kgrittn
source

Merci! J'ai examiné le fichier pg_hba.conf, mais j'avais l'impression qu'il ne régissait que la manière dont un utilisateur s'authentifie lorsqu'il se connecte à une base de données et non les privilèges dont dispose l'utilisateur dans cette même base de données.

— Microcassette

1

Un utilisateur ne peut se connecter aux bases de données que dans les conditions autorisées par pg_hba.conf. Cela inclut non seulement la combinaison utilisateur / base de données, mais également l'hôte à partir duquel ils se connectent et la méthode d'authentification autorisée. Si vous n'avez pas besoin de cette granularité de contrôle, la technique GRANT/ REVOKEdiscutée dans d'autres réponses est probablement plus simple. D'une part, vous avez simplement besoin d'une connexion à la base de données superutilisateur pour cela, par opposition à un nom de connexion au système d'exploitation permettant de modifier le fichier.

— Kgrittn

0

Je suis tombé sur ce fil en cherchant un moyen d'empêcher les utilisateurs de lister les autres noms de bases de données. Le REVOKE CONNECTn'empêche pas cela.

D'après les réponses à cette question SO, il n'y a pas de moyen (recommandable) d'y parvenir.

— AdamAL
source