CREATE ROLE in PostgreSQL: Users, Group Roles and Inheritance

В PostgreSQL нет отдельных сущностей «пользователь» и «группа» — есть одна универсальная роль. Команда CREATE ROLE создаёт и человека, который логинится, и группу, которая держит права для других ролей. Разница лишь в атрибутах, которые вы навешиваете.

Роль, которая логинится, и роль-группа

Роль с атрибутом LOGIN может подключаться к серверу — это и есть «пользователь». Роль без LOGIN подключиться не может и обычно служит контейнером прав, то есть «группой».

-- a login role: an actual person or service
CREATE ROLE analyst LOGIN PASSWORD 'secret';

-- a group role: no login, just holds privileges
CREATE ROLE app_readonly NOLOGIN;

CREATE USER — это всего лишь синоним CREATE ROLE ... LOGIN. То есть CREATE USER analyst и CREATE ROLE analyst LOGIN делают одно и то же; никакого «отдельного типа пользователя» под капотом нет.

Выдадим группе права на чтение нашей схемы:

GRANT SELECT ON users, orders, employees TO app_readonly;

Членство в ролях и наследование

Роль становится членом группы через GRANT role TO member. Дальше всё решает атрибут INHERIT: если он есть (это значение по умолчанию), член автоматически пользуется правами группы.

-- analyst now inherits everything app_readonly can do
GRANT app_readonly TO analyst;

-- as analyst, this just works thanks to inheritance:
SELECT country, count(*) FROM users GROUP BY country;

Если же роль создана с NOINHERIT, права группы не применяются автоматически — их нужно явно «надеть» командой SET ROLE:

CREATE ROLE deploy_bot LOGIN NOINHERIT PASSWORD 'secret';
GRANT app_readonly TO deploy_bot;

-- without SET ROLE the SELECT below is denied
SET ROLE app_readonly;
SELECT amount FROM orders WHERE status = 'paid';
RESET ROLE;

Грабли: атрибуты вроде SUPERUSER, CREATEDB, LOGIN через членство НЕ наследуются никогда. Член суперпользовательской группы не становится суперпользователем — унаследовать можно только обычные привилегии (SELECT, INSERT и т. п.), но не атрибуты роли.

Атрибуты роли

Атрибуты задают, что роль вправе делать на уровне всего кластера. Самые ходовые:

• LOGIN / NOLOGIN — можно ли подключаться к серверу.
• SUPERUSER / NOSUPERUSER — обходит ли роль все проверки прав. Раздавайте крайне скупо.
• CREATEDB — может ли создавать базы данных.
• CREATEROLE — может ли создавать и менять другие роли.
• PASSWORD и VALID UNTIL — пароль и дата его истечения.

CREATE ROLE etl_owner LOGIN
    CREATEDB
    PASSWORD 'secret'
    VALID UNTIL '2026-12-31';

Менять атрибуты можно потом через ALTER ROLE, и так же удобно отзывать опасные права:

ALTER ROLE analyst CONNECTION LIMIT 5;
ALTER ROLE etl_owner NOCREATEDB;

Модель «пользователи и группы»

Практичный шаблон: создаёте несколько групп-ролей под наборы прав, людей — как login-роли, и связываете их членством. Менять доступ потом — это одна команда GRANT/REVOKE, а не правка прав на каждой таблице для каждого человека.

-- groups by responsibility
CREATE ROLE readers NOLOGIN;
CREATE ROLE writers NOLOGIN;

GRANT SELECT ON users, orders TO readers;
GRANT SELECT, INSERT, UPDATE ON orders TO writers;

-- writers should also be able to read
GRANT readers TO writers;

-- people
CREATE ROLE maria LOGIN PASSWORD 'secret';
CREATE ROLE pavel LOGIN PASSWORD 'secret';

GRANT readers TO maria;
GRANT writers TO pavel;

Когда Павел уходит из команды записи, вы делаете REVOKE writers FROM pavel — и доступ снимается со всех таблиц разом.

Различия в движках:

• MySQL до версии 8.0 ролей не имел вовсе; теперь есть CREATE ROLE и CREATE USER, но это разные команды, а роль нужно ещё активировать через SET ROLE или SET DEFAULT ROLE.
• ClickHouse поддерживает CREATE ROLE, CREATE USER и GRANT, но модель прав плоская и без глубокого наследования через цепочки ролей.

Базовое правило: права вешайте на группы, людей делайте членами групп, а SUPERUSER держите только у платформенных администраторов. Тогда новый человек получает доступ одной командой членства, а уходящий — теряет его так же быстро, и аудит сводится к просмотру списка групп, а не прав на каждой таблице.

Если модель ролей стала трудно объяснимой за минуту, она уже слишком сложна для эксплуатации. Держите роли именованными по обязанностям, а не по людям, и регулярно проверяйте цепочки членства.