J'ai un script assez simple pour créer une nouvelle base de données et pour créer un nouvel utilisateur pour accéder à cette base de données. Il est exécuté par l'utilisateur postgres par défaut. Après avoir accordé l'accès à la base de données et au schéma à l'utilisateur, l'utilisateur nouvellement créé n'est toujours pas en mesure de voir les tables à l'aide de \dt
Dans psql. Voici quelques extraits du script pour montrer ce que j'ai essayé jusqu'à présent:
CREATE USER api WITH ENCRYPTED PASSWORD 'password';
ALTER DEFAULT PRIVILEGES
FOR USER api
IN SCHEMA public
GRANT ALL ON ALL TABLES TO api;
DROP DATABASE IF EXISTS new_db;
CREATE DATABASE new_db;
CREATE TABLE addresses (
address_id INTEGER,
address_line_1 VARCHAR(50) NOT NULL,
address_line_2 VARCHAR(50),
city VARCHAR(50) NOT NULL,
state VARCHAR(2) NOT NULL,
zipcode VARCHAR(12) NOT NULL,
PRIMARY KEY (address_id)
);
-- Create more tables....
-- Added these in for good measure at the end:
GRANT all PRIVILEGES on DATABASE new_db to api;
GRANT ALL ON DATABASE new_db TO api;
GRANT ALL ON SCHEMA public to api;
GRANT ALL ON ALL TABLES IN SCHEMA public TO api;
Après avoir exécuté cela, \dt
Affiche toutes les tables en psql lorsque vous êtes connecté en tant qu'utilisateur postgres. \dt
Affiche Did not find any relations.
Lorsqu'il est connecté en tant qu'utilisateur api.
L'exécution de \dn+
Avec l'utilisateur postgres me donne ces informations:
Name | Owner | Access privileges | Description
--------+----------+-----------------------+------------------------
public | postgres | postgres=UC/postgres +| standard public schema
| | =UC/postgres +|
| | api=UC/postgres |
Informations sur la version: PostgreSQL 10.5 (Ubuntu 10.5-2.pgdg16.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609, 64-bit
Autres SO questions que j'ai rencontrées jusqu'à présent:
J'ai regardé d'innombrables SO questions et essayé tout ce qui est suggéré, mais toujours pas de chance. Y a-t-il autre chose que je peux vérifier ou essayer? Mon intuition est que je manque quelque chose d'évident.
Créez un groupe, ce qui signifie un ROLE
avec NOLOGIN
.
CREATE ROLE api_group NOLOGIN;
Créez (ou déposez d'abord si vous le souhaitez) votre base de données. Et puis connectez-vous à cette base de données.
CREATE DATABASE new_db;
\c new_db
Ajoutez des privilèges par défaut pour votre groupe. Le code ci-dessous indique si le rôle postgres
crée une attribution d'objet ALL
au rôle api_group
. Au lieu de TOUT, vous pouvez être plus spécifique (par exemple, SELECT, INSERT, USAGE, etc.).
ALTER DEFAULT PRIVILEGES FOR ROLE postgres ALL ON TABLES TO api_group ;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres ALL ON SEQUENCES TO api_group ;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres GRANT ALL ON FUNCTIONS TO api_group ;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres GRANT ALL ON TYPES TO api_group ;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres GRANT ALL ON SCHEMAS TO api_group ;
Vous pouvez maintenant utiliser l'utilisateur postgres
pour créer de nouveaux objets.
CREATE TABLE addresses (
address_id INTEGER,
address_line_1 VARCHAR(50) NOT NULL,
address_line_2 VARCHAR(50),
city VARCHAR(50) NOT NULL,
state VARCHAR(2) NOT NULL,
zipcode VARCHAR(12) NOT NULL,
PRIMARY KEY (address_id)
);
-- Create more objects....
La configuration est prête. Si vous ajoutez un nouvel utilisateur (disons) api
même après avoir créé tous les objets, l'utilisateur aura tous les privilèges. Le mot clé INHERIT
permet d'hériter des privilèges des rôles dont il est membre. Les codes ci-dessous créent 2 utilisateurs en tant que membre de api_group
.
CREATE ROLE api INHERIT WITH ENCRYPTED PASSWORD 'pwd' IN ROLE api_group;
CREATE ROLE another_api INHERIT WITH ENCRYPTED PASSWORD 'pwd' IN ROLE api_group;
Sections suggérées de la documentation;
Lorsque je suis les étapes que vous donnez, le tableau créé est visible pour le rôle "api". Mais, la table n'est pas dans la base de données "new_db", car vous ne vous êtes pas converti dans cette base de données après avoir créé la base de données mais avant de créer la table. En outre, la table n'appartient pas à "api", car vous n'avez pas changé de rôle après l'avoir créé mais avant de créer la table. La table se trouve et est donc visible dans la même base de données à laquelle vous vous êtes connecté à l'origine (vraisemblablement "postgres") et appartient au rôle "postgres".
Le alter default privileges
n'accomplit rien car il s'applique aux tables créées par "api", mais vous n'avez pas créé la table en tant que "api". De plus, cela ne ferait rien de toute façon car le propriétaire d'une table a déjà des privilèges sur sa propre table par défaut.
Si vous pouvez voir le tableau lorsque vous vous connectez en tant que "postgres", mais pas lorsque vous vous connectez en tant que "api", cela doit être parce que vous vous connectez pas à la même base de données que chaque utilisateur. Si vous vous connectez à la base de données "new_db" en tant que rôle "postgres", vous ne verrez pas le tableau car il n'y est pas. Si vous vous connectez à la base de données "postgres" en tant que rôle "api", vous le verrez.