Re: Port Reports: UnixWare/Failure/Priviledge Test

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Port Reports: UnixWare/Failure/Priviledge Test
Дата
Msg-id 20136.1067460593@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Port Reports: UnixWare/Failure/Priviledge Test  (Larry Rosenman <ler@lerctr.org>)
Ответы Re: Port Reports: UnixWare/Failure/Priviledge Test  (Larry Rosenman <ler@lerctr.org>)
Список pgsql-hackers
Larry Rosenman <ler@lerctr.org> writes:
> --On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane=20
> <tgl@sss.pgh.pa.us> wrote:
> [snip]
>> Is this a bug, or is it correct-per-spec behavior?  It's surely likely
>> to confuse people.  I wonder whether superusers shouldn't be allowed to
>> revoke privileges granted by other people.  As the code stands, they
>> cannot.

> It seems to me that a superuser SHOULD be able to affect ANY permissions on
> ANY object in the DB.

Well, of course a superuser can do SET SESSION AUTHORIZATION to "become"
the other person, and then execute GRANT or REVOKE commands to update
the permissions as he wishes.  This seems reasonable for the GRANT case
(otherwise we'd need to add a clause to GRANT to specify which userid to
grant the permissions as).  For REVOKE, though, I'm wondering if a
superuser-issued REVOKE shouldn't revoke the specified permissions
regardless of who granted them.

An alternative, possibly cleaner approach is that a superuser-issued
GRANT or REVOKE should be executed as though it were issued by the
object owner.  This would mean that all privileges ultimately flow from
the object owner, which seems reasonable intuitively.  Right now, you
can have a situation where some privileges on an object are granted by
the owner and some are granted by various random superusers.  Not sure
that that is a good idea.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: 7.4 compatibility question
Следующее
От: Larry Rosenman
Дата:
Сообщение: Re: Port Reports: UnixWare/Failure/Priviledge Test