Date: Wed, 2 Jul 2008 16:15:53 +0700
From: sftf <sftf-misc@mail.ru>
Reply-To: sftf <sftf-misc@mail.ru>
Message-ID: <1888544450.20080702161553@mail.ru>
To: pgsql-ru-general@postgresql.org,
 "pronix pronix" <pronix.service@gmail.com>
Subject: 
 =?Windows-1251?B?UmVbMl06IFtwZ3NxbC1ydS1nZW5lcmFsXSDQ7uvoOiDz7/Dg4uvl7ejl?=
	=?Windows-1251?B?IOTu8fLz7+7sIOog5PDz4+jsIPDu6//sLiDQ7uvoIOrg6iDu4frl6vL7?=
	=?Windows-1251?B?IPHo8fLl7Psg4eXn7u/g8e3u8fLoLg==?=
In-Reply-To: <639ce0480807020100i43212fe0jf53d9f74905f30d8@mail.gmail.com>
References: <417367745.20080702111958@mail.ru>
	<639ce0480807020100i43212fe0jf53d9f74905f30d8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit

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 ]