Re: [v9.3] Row-Level Security

Поиск
Список
Период
Сортировка
От Kohei KaiGai
Тема Re: [v9.3] Row-Level Security
Дата
Msg-id CADyhKSWTWVmYgW2o8pyTXxC0gUfigXwh+GcmN02U4DrGTfaxRQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.3] Row-Level Security  (Florian Pflug <fgp@phlo.org>)
Ответы Re: [v9.3] Row-Level Security  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
2012/6/27 Florian Pflug <fgp@phlo.org>:
> On Jun27, 2012, at 15:07 , Kohei KaiGai wrote:
>> Probably, PlannedStmt->invalItems allows to handle invalidation of
>> plan-cache without big code changes. I'll try to put a flag of user-id
>> to track the query plan with RLS assumed, or InvalidOid if no RLS
>> was applied in this plan.
>> I'll investigate the implementation for more details.
>>
>> Do we have any other scenario that run a query plan under different
>> user privilege rather than planner stage?
>
> Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
>
> Actually, I wonder how we handle that today. If the executor is
> responsible for permission checks, that wouldn't we apply the calling
> function's privilege level in that case, at least of the cursor isn't
> fetched from in the SECURITY DEFINER function? If I find some time,
> I'll check...
>
My impression is, here is no matter even if SECURITY DEFINER function
returns refcursor.

A SECURITY DEFINER function (or Trusted Procedure on sepgsql, or
Set-UID program on Linux) provides unprivileged users a particular
"limited way" to access protected data. It means owner of the security
definer function admits it is reasonable to show the protected data
as long as unprivileged users access them via the function.

It is same reason why we admit view's access for users who have
privileges on views but unprivileged to underlying tables.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Patch-2 (2-move-continuation-record-to-page-header.patch) WAL Format Changes
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: experimental: replace s_lock spinlock code with pthread_mutex on linux