From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org, sfrost(at)snowman(dot)net |
Subject: | Re: [RFC] A tackle to the leaky VIEWs for RLS |
Date: | 2010-06-01 13:16:13 |
Message-ID: | AANLkTikLawxkvDQO1t0pUi5ysBxigYbvdLTjg8OZt1gU@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/6/1 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-06-01 13:37:30 | Re: is_absolute_path incorrect on Windows |
Previous Message | Robert Haas | 2010-06-01 13:09:30 | Re: [RFC] A tackle to the leaky VIEWs for RLS |