Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re[2]: [pgsql-ru-general] Роли: управление доступом к другим ролям. Роли как объекты системы безопасности.

Разрабатываю приложение с использованием Postgres.
Обнаружил, что нет возможности управлять тем, что может делать данная роль с другими ролями.
Собственно, интересует: такой возможности не существует по каким-то иделогическим или техническим причинам?

Для примера, что собственно я хотел реализовать.
В разарабатываемом приложении, я хотел части пользователей (менеджерам отделов) дать возможность
создавать пользователей и назначать им роли из ограниченного списка ролей.
Для этого я предполагал создвать роли менеджеров так: CREATE ROLE manager NOSUPERUSER CREATEROLE...
Однако, согласно существующей сейчас в Postgres модели безопасности, роль с привелегикй 'CREATEROLE'
может изменять или удалять ЛЮБЫЕ другие роли, кроме SUPERUSER.
Таким образом, создав в системе двух менеджеров невозможно разграничить их возможности по управлению
ролями "своих" и "чужих" сотрудников, и вообще любых других ролей кроме суперюзеров.
Они даже смогут поменять пароли друг у друга.

Я начал в документации искать следующие возможности:
- наличие подчиненности ролей (роль имеет роль-создателя)
- GRANT описывающий, какие именно существующие роли, данная роль может назначать вновь создаваемым ролям
- GRANT описывающий, какие роли данная роль может изменять (включая: какие какие именно параметры роли)
- GRANT описывающий, какие роли данная роль может удалять
К сожалению таких возможностей не оказалось.
Кстати, даже в ORACLE таких возможностей нет, за исключением раздельных системых привелегий
CREATE/ALTER/DROP USER, что в данной ситуации ничего существенно не меняет.

Конечно можно эту задачу решить на уровне приложения: продублировать список ролей в пользовательской
таблице с дополнительной информацией (владельцы ролей, права ролей на другие роли) и создавать/изменять
роли Postgres через хранимые процедуры+Dynamic SQL (не знаю пока еще, поддерживется дли динамический SQL в Postgres).

Но все же удивительно, почему роли не являются такими же объектами в DAC как и другие объекты СУБД:
таблицы, представления, процедуры и т.д.?

pp> Посмотри ссылку - кажется это то, что вы ищете  http://www.postgresql.org/docs/8.3/interactive/role-membership.html
Спасибо, но это не то.
Да, там идет речь о наследовании привелегий ролей.
Но нет механизма контроля прав доступа одной роли по отношению к другой.
Пример:
есть два менеджера с возможность создавать роли пользователей
СREATE ROLE manager1 LOGIN NOSUPERUSER CREATEROLE
СREATE ROLE manager2 LOGIN NOSUPERUSER CREATEROLE

и есть две созданные админом групповые роли
СREATE ROLE view_doc NOLOGIN NOSUPERUSER NOCREATEROLE
СREATE ROLE edit_doc NOLOGIN NOSUPERUSER NOCREATEROLE

Проблема №1: неуправляемые права ролей с привиоегией CREATEROLE по отношению к другим не суперюзерским ролям.
Например, manager1 и manager2 смогуть изменить или удалить роли
view_doc и edit_doc, что нежелательно. В ORACLE хотя бы можно не давать им ALATER ANY ROLE и DROP ANY ROLE.
Но даже этого недостаточно.
Далее, рассмотрим следующие действия менеджеров:
manager1:
СREATE ROLE user1 LOGIN NOSUPERUSER NOCREATEROLE -- manager1 создал сотрудника своего отдела

manager2:
СREATE ROLE user2 LOGIN NOSUPERUSER NOCREATEROLE -- manager2 создал сотрудника своего отдела

Теперь manager1 может изменить/удалить сотрудника "не своего отдела": ALTER ROLE user2...,
а manager2 тоже может изменить/удалить "чужого" сотрудника: ALTER ROLE user1...

Проблема №2: ограниченые возможности по котнролю присвоения ролей.
Рассмотрим вариант, когда manager1 должен иметь возможность раздавать только роль view_doc только своим сотрудникам.
manager1:
GRANT view_doc to user1
Однако он сможет сделать и так
GRANT view_doc to user2, чего быть не должно.
Нет возможности задать кому именно manager1 может раздать присвоенные ему самому роли.

Т.е. привелегия CREATEROLE слишком мощна и содержит в себе много привелегий.
Рассмотрим вариант менеджеров без привелегии CREATEROLE (т.е. NOCREATEROLE).
1. Они сразу же потеряют возможность создавать роли пользователей, а нам это нужно.
2. Если мы сделаем так, чтобы менджер хотя бы сам мог раздавать роли:
GRANT view_doc to manager1 with admin option
то тут две проюлемы:
a) manager1 сам дожен имет раздавемые им роли, что не всегда приемлемо
б) нет возможности управлять КОМУ ИМЕННО manager1 может назначить каждую имеющуюся у него роль

Итого: было бы хорошо, если бы роли могли выступать объектами, по отношению к которым назначаются права доступа.
Типа:
кто может создавaть | удалять какие роли
GRANT { { CREATE | DROP }
[,...] | ALL [ PRIVILEGES ] }
ON { {ROLE rolename [, ...]} | ANY ROLE}
TO { rolename } [, ...] [ WITH ADMIN OPTION ]

кто, что и в каких ролях может менять
GRANT ALTER { LOGIN | PASSWORD | INHERIT | RENAME | VALID | SET | и т.д. }
ON ROLE rolename [, ...]
TO { rolename } [, ...] [ WITH ADMIN OPTION ]

кто какие роли и кому может назначать
GRANT GRANT {ANY | rolename}
ON ROLE rolename [, ...]
TO { rolename } [, ...] [ WITH GRANT OPTION ]

AK> В данном примере роли пользователей (менеджеры отделов) по-моему относятся
AK> больше с пользовательскому приложению, а не к СУБД, соотвественно связь
AK> между менеджерами и другими пользователями можно сделать на уровне приложения.

В данном конкретном случае скорее да.
Однако если рассмотреть, как я считаю, вполне реалистичный вариант администрирования
БД (не приложения!) группой админов - каждый со своим "набором" подчиненных пользователей:
Главный админ
/ \
/ \
/ \
админ1 адимн2
/ | \ / | \
обычные пользователи1 обычные пользователи2

То тут весьма желателен механизм управления
"кто какими пользователями имеет право управлять и кто какими ролями имеет право распоряжаться".

"кто какими ролями имеет право распоряжаться" решить - дав эти роли админу с admin option, но
а) невозможно ограничить круг пользователей, которым админ1 может назначить имеющиеся у него самого роли
б) сами эти роли админу не часто не нужны - достаточно чтобы он мог ими распоряжаться, но не не имет эту роль

В приложении, наличие такого функионала в БД упростило бы его разработку.
Спасибо.

Спор, нужен или нет такой функционал, помоему не имеет смысла.
Такой функционал однозначно нужен. Более того, ИМХО он обязателен для
DB претендующей на Энтерпрайз.
Для полного счастья осталось узнать какие шансы увидеть данный
функционал в PostgreSQL

3 июля 2008 г. 13:12 пользователь sftf <sftf-misc(at)mail(dot)ru> написал:
> AK> В данном примере роли пользователей (менеджеры отделов) по-моему относятся
> AK> больше с пользовательскому приложению, а не к СУБД, соотвественно связь
> AK> между менеджерами и другими пользователями можно сделать на уровне приложения.
>
> В данном конкретном случае скорее да.
> Однако если рассмотреть, как я считаю, вполне реалистичный вариант администрирования
> БД (не приложения!) группой админов - каждый со своим "набором" подчиненных пользователей:
> Главный админ
> / \
> / \
> / \
> админ1 адимн2
> / | \ / | \
> обычные пользователи1 обычные пользователи2
>
> То тут весьма желателен механизм управления
> "кто какими пользователями имеет право управлять и кто какими ролями имеет право распоряжаться".
>
> "кто какими ролями имеет право распоряжаться" решить - дав эти роли админу с admin option, но
> а) невозможно ограничить круг пользователей, которым админ1 может назначить имеющиеся у него самого роли
> б) сами эти роли админу не часто не нужны - достаточно чтобы он мог ими распоряжаться, но не не имет эту роль
>
> В приложении, наличие такого функионала в БД упростило бы его разработку.
> Спасибо.
>
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>

VK> Спор, нужен или нет такой функционал, помоему не имеет смысла.
VK> Такой функционал однозначно нужен. Более того, ИМХО он обязателен для
VK> DB претендующей на Энтерпрайз.
VK> Для полного счастья осталось узнать какие шансы увидеть данный
VK> функционал в PostgreSQL
Для меня самое удивительное, что в такой Enterprise БД как ORACLE таких возможностей тоже нет.

sftf wrote:
> Но нет механизма контроля прав доступа одной роли по отношению к другой.

> Проблема #1: неуправляемые права ролей с привиоегией CREATEROLE по отношению к другим не суперюзерским ролям.
> Проблема #2: ограниченые возможности по котнролю присвоения ролей.

create table usr (
name text primary key,
privileges text
);

create function create_usr (text, text) returns int as $$
declare priv text;
begin
select into priv privileges from usr where name=session_user;
if not my_mega_system_is_admin(priv) then
return 0;
end if;
create role $1 nosuperuser nocreaterole;
insert into usr values ($1,$2);
end;
$$ language plpgsql security definer;

это только СХЕМАТИЧЕСКИЙ ПРИМЕР.

Идея в следущем.
Вы свои привилегии которыми хотите наделить юзеров храните в своей
специально (идеально) предназначенной для этого таблице И все ваши
админы и неадмины НЕ суперюзеры И управляете содержимым этой таблицы при
помощи SECURITY DEFINER функции, которая основываясь на данных о
привилегиях либо создаёт для вас юзера либо не создаёт.

Разумеется функций будет не одна и их можно зацепить за триггеры.
и вообще расширить систему прав КАК ПОЖЕЛАЕТЕ.