Re: Mystery with REVOKE PRIVILEGE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Mystery with REVOKE PRIVILEGE
Date
Msg-id 1757365.1768944751@sss.pgh.pa.us
Whole thread Raw
In response to Re: Mystery with REVOKE PRIVILEGE  (Konstantin Knizhnik <knizhnik@garret.ru>)
Responses Re: Mystery with REVOKE PRIVILEGE
List pgsql-hackers
Konstantin Knizhnik <knizhnik@garret.ru> writes:
>> The problem really seems to be in `select_best_grantor` - it choose 
>> "wrong" grantor.
>> It seems to be the bug because as a result of this operation no 
>> privilege is revoked at all (because then `merge_acl_with_grant` found 
>> no match).
>> I wonder if `select_best_grantor` should always prefer exact match?

> I mean something like this (see attached patch).

I don't think "let's make select_best_grantor even more magic"
is the right approach.  IMO, if there is a GRANTED BY clause,
we should use exactly that grantor and not apply select_best_grantor
at all.  This is, for example, certainly the behavior needed for
pg_dump.

If I'm reading the SQL spec correctly, it only allows "GRANTED BY
CURRENT_ROLE" and "GRANTED BY CURRENT_USER", so we're already
extending the spec by accepting "GRANTED BY somebody".  But it's
really hard to find any justification for select_best_grantor in
the spec.  I think we ought to redefine that as a legacy behavior
we use in the absence of any explicit GRANTED BY clause.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: pg_stat_statements: Fix nested tracking for implicitly closed cursors
Next
From: Nathan Bossart
Date:
Subject: Re: Mystery with REVOKE PRIVILEGE