From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: leaky views, yet again |
Date: | 2010-10-13 17:19:27 |
Message-ID: | 29129.1286990367@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> You seem to believe that being able to infer the total size of a
> table or the frequency of some particular key in the table is
> equivalent to being able to trivially read every row of it.
I don't say that they're equivalent. I do say that what this patch is
mostly trying to do is solve a PR problem, and from the PR standpoint
it doesn't help: the "OMG Postgres exposes my information" crowd is not
going to distinguish leaks that only expose MCVs from those that
trivially allow sucking out the entire table. There are furthermore
plenty of situations where statistical information *is* of interest to
attackers; the traditional example is obtaining the min and max of a
salary column to infer something about what particular people are
getting paid. So I think if we accept this patch or something like it,
we are going to spend a large part of the next ten years trying to close
other holes of the same ilk, and that's not a development plan I'm
willing to buy into. I am much happier just making the statement that
we don't try to prevent that type of leak than giving people the
impression that we are committed to trying to prevent it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-10-13 17:38:39 | Re: SQL command to edit postgresql.conf, with comments |
Previous Message | Radosław Smogura | 2010-10-13 17:17:48 | Re: [JDBC] Support for JDBC setQueryTimeout, et al. |