cursors, current_user, and SECURITY DEFINER

Поиск
Список
Период
Сортировка
От Michael Fuhr
Тема cursors, current_user, and SECURITY DEFINER
Дата
Msg-id 20060710031343.GA84901@winnie.fuhr.org
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: pgsql-patches considered harmful
Следующее
От: Greg Stark
Дата:
Сообщение: row() is [not] null infelicities