Re: When and where to check for function permissions
От | Rod Taylor |
---|---|
Тема | Re: When and where to check for function permissions |
Дата | |
Msg-id | 011001c1b4dd$249919b0$8001a8c0@jester обсуждение исходный текст |
Ответ на | When and where to check for function permissions (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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 >
В списке pgsql-hackers по дате отправления: