From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | cursors, current_user, and SECURITY DEFINER |
Date: | 2006-07-10 03:13:43 |
Message-ID: | 20060710031343.GA84901@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While replying to the "information_schema for all users" thread in
pgsql-sql I noticed that a cursor returned from a SECURITY DEFINER
function evalutes current_user as the user who executes FETCH, not
as the user who defined the function that opened the cursor. Here
are the question and my response, which contains an example:
http://archives.postgresql.org/pgsql-sql/2006-07/msg00137.php
http://archives.postgresql.org/pgsql-sql/2006-07/msg00140.php
I can understand that evaluating current_user at FETCH time makes
sense from an execution standpoint, but what user should it evaluate
to? In one sense current_user is the user who executed FETCH, but
since the cursor was opened with the function definer's privileges,
one might argue that the cursor's current_user ought to be the
function definer. Is the current behavior intentional? If so,
what's the rationale? If not, are there good reasons for doing it
one way or the other? I haven't considered the implications
thoroughly enough to have a position either way.
--
Michael Fuhr
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-07-10 03:26:21 | row() is [not] null infelicities |
Previous Message | Greg Stark | 2006-07-10 03:00:52 | pgsql-patches considered harmful |