Re: [RFC] A tackle to the leaky VIEWs for RLS

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [RFC] A tackle to the leaky VIEWs for RLS
Дата
Msg-id AANLkTikLawxkvDQO1t0pUi5ysBxigYbvdLTjg8OZt1gU@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] A tackle to the leaky VIEWs for RLS  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: [RFC] A tackle to the leaky VIEWs for RLS  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
2010/6/1 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
> The general problem is that it seems like a nightmare to maintain this
> throughout the planner. Who knows what optimizations this affects, and
> do we need to hide things like row-counts in EXPLAIN output? If we try
> to be very strict, we can expect a stream of CVEs and security releases
> in the future while we find holes and plug them. On the other hand,
> using views to restrict access to underlying tables is a very useful
> feature, so I'd hate to just give up. We need to decide what level of
> isolation we try to accomplish.

I'm entirely uninspired by the idea of trying to prevent all possible
leakage of information via side-channels.  Even if we tried to
obfuscate the explain output, the user can still potentially get some
information by timing how long queries take to execute.  I think if we
have a hook function that can prevent certain users from running
EXPLAIN altogether (and I believe this may already be the case) that's
about the appropriate level of worrying about that case.  I think the
only thing that we can realistically prevent is allowing users to make
off with the actual tuples.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [RFC] A tackle to the leaky VIEWs for RLS
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: is_absolute_path incorrect on Windows