Помоему, это очень не грамотный подход, делить роли для приложения и
для базы данных.
2 июля 2008 г. 14:26 пользователь Alexey Klyukin
<alexk@commandprompt.com> написал:
> Привет,
>
> sftf wrote:
>>
>> Для примера, что собственно я хотел реализовать.
>> В разарабатываемом приложении, я хотел части пользователей (менеджерам отделов) дать возможность
>> создавать пользователей и назначать им роли из ограниченного списка ролей.
>> Для этого я предполагал создвать роли менеджеров так: CREATE ROLE manager NOSUPERUSER CREATEROLE...
>> Однако, согласно существующей сейчас в Postgres модели безопасности, роль с привелегикй 'CREATEROLE'
>> может изменять или удалять ЛЮБЫЕ другие роли, кроме SUPERUSER.
>> Таким образом, создав в системе двух менеджеров невозможно разграничить их возможности по управлению
>> ролями "своих" и "чужих" сотрудников, и вообще любых других ролей кроме суперюзеров.
>> Они даже смогут поменять пароли друг у друга.
>
> В данном примере роли пользователей (менеджеры отделов) по-моему относятся
> больше с пользовательскому приложению, а не к СУБД, соотвественно связь
> между менеджерами и другими пользователями можно сделать на уровне приложения.
>
>>
>> Конечно можно эту задачу решить на уровне приложения: продублировать список ролей в пользовательской
>> таблице с дополнительной информацией (владельцы ролей, права ролей на другие роли) и создавать/изменять
>> роли Postgres через хранимые процедуры+Dynamic SQL (не знаю пока еще, поддерживется дли динамический SQL в
Postgres).
>
> Динамический SQL поддерживается. Т.е. из встраиваемых функций можно
> выполнять SQL запросы, сформированные кодом этих функций.
>
> P.S. это forward, забыл сделать cc на рассылку.
>
> --
> Alexey Klyukin http://www.commandprompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>