Curiosity got me...
User 1: Create table; grant all on table to public;
User 2: select * from table for update;
User 1: revoke all on table from public;
User 2: update table set column = column + 1;
As long as User 2 holds a lock on the rows shouldn't the user have
access to the rows? I'd expect the revoke statement to be blocked by
the locks on those rows.
--
Rod Taylor
This message represents the official view of the voices in my head
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Peter Eisentraut" <peter_e@gmx.net>
Cc: "PostgreSQL Development" <pgsql-hackers@postgresql.org>
Sent: Wednesday, February 13, 2002 5:01 PM
Subject: Re: [HACKERS] When and where to check for function
permissions
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Now I remembered the way SQL99 specifies
> > function resolution, which has the permission check before the
function
> > resolution begins.
>
> That may be what the spec says, but I think the spec is completely
> brain-dead in this regard and should be ignored. We do not resolve
> table names that way, why should we resolve function names?
>
> Even more to the point, what happens when someone adds or revokes
> privileges that would affect already-planned queries? If I can
still
> call a function that is referenced by an already-planned query even
> though the function's owner has revoked my right to do so, that is a
> bug. On the other hand, if the query continues to "work" but
silently
> calls a different function than I was expecting, that's not cool
either.
>
> We did some nontrivial work awhile back to ensure that table
privileges
> would be checked at execution time and not before. Function
privileges
> *must* be handled the same way.
>
> regards, tom lane
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
