cursors, current_user, and SECURITY DEFINER - Mailing list pgsql-hackers

From Michael Fuhr
Subject cursors, current_user, and SECURITY DEFINER
Date
Msg-id 20060710031343.GA84901@winnie.fuhr.org
Whole thread Raw
List 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


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: pgsql-patches considered harmful
Next
From: Greg Stark
Date:
Subject: row() is [not] null infelicities