Re: PRIVATE columns - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: PRIVATE columns
Date
Msg-id 50C8EC0E.4080109@commandprompt.com
Whole thread Raw
In response to Re: PRIVATE columns  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 12/12/2012 12:12 PM, Simon Riggs wrote:

>> Would protecting it the same way, we protect the passwords in pg_authid, be
>> sufficient?
>
> The user backend does need to be able to access the stats data during
> optimization. It's hard to have data accessible and yet impose limits
> on the uses to which that can be put. If we have row security on the
> table but no equivalent capability on the stats, then we'll have
> leakage. e.g. set statistics 10000, ANALYZE, then leak 10000 credit
> card numbers.
>
> Selectivity functions are not marked leakproof, nor do people think
> they can easily be made so. Which means the data might be leaked by
> various means through error messages, plan selection, skullduggery
> etc..
>
> If it ain't in the bucket, the bucket can't leak it.
>

I accidentally responded to Simon off-list to this. I understand the 
need and think it would be a good thing to have. However, the real 
opportunity here is to make statistics non-user visible. I can't think 
of any reason that they need to be visible to the standard user? Even if 
when we set the statistics private, it makes just that column non-visible.

Sincerely,

Joshua D. Drake



-- 
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: PRIVATE columns
Next
From: Dimitri Fontaine
Date:
Subject: Re: Use of systable_beginscan_ordered in event trigger patch