Re: Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

Russell Smith wrote:
> Alvaro Herrera wrote:
> >Alvaro Herrera wrote:
> >
> >
> >>2. decide that the standard is braindead and just omit dumping the
> >> grantor when it's no longer available, but don't remove
> >> pg_auth_members.grantor
> >>
> >>Which do people feel should be implemented? I can do whatever we
> >>decide; if no one has a strong opinion on the matter, my opinion is we
> >>do (2) which is the easiest.
> >
> >Here is a patch implementing this idea, vaguely based on Russell's.
>
> I haven't had time to finalize my research about this, but the admin
> option with revoke doesn't appear to work as expected.
>
> Here is my sample SQL for 8.2.4
>
> create table test (x integer);
> \z
> create role test1 noinherit;
> create role test2 noinherit;
> grant select on test to test1 with grant option;
> grant select on test to test2;
> \z test
> set role test1;
> revoke select on test from test2;
> \z test
> set role test2;
> select * from test;
> reset role;
> revoke all on test from test2;
> revoke all on test from test1;
> drop role test2;
> drop role test1;
> drop table test;
> \q
>
>
> The privilege doesn't appear to be revoked by test1 from test2. I'm not
> sure if this is related, but I wanted to bring it up in light of the
> options we have for grantor.

Humm, but the privilege was not granted by test1, but by the user you
were using initially. The docs state in a note that

A user can only revoke privileges that were granted directly by
that user.

I understand that this would apply to the grantor stuff being discussed
in this thread as well, but I haven't seen anyone arguing that we should
implement that for GRANT ROLE (and I asked three times if people felt it
was important and nobody answered).

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support