Re: When and where to check for function permissions

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(at)sss(dot)pgh(dot)pa(dot)us>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Cc: "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Sent: Wednesday, February 13, 2002 5:01 PM
Subject: Re: [HACKERS] When and where to check for function
permissions

> Peter Eisentraut <peter_e(at)gmx(dot)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
>