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@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
>