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> |
Subject: | Re: When and where to check for function permissions |
Date: | 2002-02-13 22:01:34 |
Message-ID: | 998.1013637694@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-02-13 22:07:54 | Re: NAMEDATALEN Changes |
Previous Message | Tom Lane | 2002-02-13 21:53:48 | Re: NAMEDATALEN Changes |