Re: Why grantor is owner in this case?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why grantor is owner in this case?
Дата
Msg-id 10042.1262013577@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why grantor is owner in this case?  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-general
Alvaro Herrera <alvherre@commandprompt.com> writes:
> donniehan wrote:
>> I'm sorry to bother you. i really care about this behavior, but i couldn't find the discussions you mentioned in
pgsql-hackersarchives. 
>> Would you please tell me more about the discussions(about date? the related issue?), so that i can search it and
findit more easily?  

> Maybe he's referring to this discussion:
> http://archives.postgresql.org/message-id/1176775180.4152.97.camel%40dogma.v10.wvs

No, it's a lot older than that.  See
http://archives.postgresql.org/pgsql-hackers/2003-10/msg01497.php
http://archives.postgresql.org/pgsql-committers/2003-10/msg00305.php

The original 7.4-devel behavior made it effectively impossible for a
superuser to *revoke* privileges, which is certainly not acceptable in
practice.

Looking at the CVS history of aclchk.c, I notice that we later installed
a similar provision with respect to roles: grants/revokes are done as
the role that owns the object, not as the role member that is actually
issuing the command.  Otherwise other role members can't adjust the
privileges.

This comes down to the fact that privileges granted on the same object
by two different roles are distinct, and you can only revoke the ones
you granted.  Which AFAICT is required behavior per SQL spec.

            regards, tom lane

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

Предыдущее
От: Ivano Luberti
Дата:
Сообщение: Re: Java Postgres drivers.
Следующее
От: Jaime Casanova
Дата:
Сообщение: Re: How to use read uncommitted transaction level and set update order