On Tue, Oct 5, 2010 at 2:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
