On Tue, Oct 5, 2010 at 2:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> On 05.10.2010 21:08, Greg Stark wrote:
>>> If the users that have select access on the view don't have DDL access
>>> doesn't that make them leak-proof for those users?
>
>> No. You can use built-in functions for leaking data as well.
>
> There's a difference between "can be used to extract data wholesale"
> and "can be used to probe for the existence of a specific value".
> We might need to start using more specific terminology than "leak".
Yeah. There are a lot of cases. The worst is if you can (1a) dump
the underlying table wholesale, or maybe (1b) extract it one row at a
time or something like that. Not quite as bad is if you can (2) infer
the presence or absence of particular values in particular columns,
e.g. via division-by-zero. This is still pretty bad though, because
you can probably just keep guessing until you eventually can enumerate
everything in that column. If it's a text field or a UUID that may be
pretty hard, but if the range of interesting values for that column is
limited to, say, a million or so, then you can just iterate through
them until you find everything. A related problem is where you can
(3) infer the frequency of a value based on the plan choice, either by
viewing the EXPLAIN output directly or by timing attacks; and then
there's (4) the ability to infer something about the overall amount of
data in the underlying table. Any others?
Of those, I'm inclined to think that it's possible to close off (1)
and (2) pretty thoroughly with sufficient care, but the best you'd be
able to do for (3) and (4) is refuse to EXPLAIN to a user without
sufficient privileges; the timing attacks seem intractable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company