Re: Column Redaction

On 10 October 2014 11:35, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Simon,
>
> * Simon Riggs (simon(at)2ndquadrant(dot)com) wrote:
>> The requirement for redaction cannot be provided by a view.
>>
>> A view provides a single value for each column, no matter whether it
>> is used in SELECT or WHERE clause.
>>
>> Redaction requires output formatting only, but unchanged for other purposes.
>>
>> Redaction is now a feature available in other databases. I guess its
>> possible its all smoke and mirrors, but thats why we discuss stuff
>> before we build it.
>
> In general, I'm on-board with the idea and similar requests have come
> from users I've talked with.
>
> Is there any additional information available on how these other
> databases deal with the questions and concerns which have been raised?
>
> Regarding functions, 'leakproof' functions should be alright to allow,
> though Heikki brings up a good point regarding binary search being
> possible in a plpgsql function (or even directly by a client). Of
> course, that approach also requires that you have a specific item in
> mind. Methods to mitigate would include not allowing regular users to
> create functions or run DO blocks and rate-limiting their queries, along
> with appropriate auditing.

To be honest, this all sounds rather flaky. Even if you do rate-limit
their queries, they can use methods that avoid rate-limiting, such as
recursive queries. And if you're only after one credit card number
(to use the original example), you'd get it in a relatively short
amount of time, despite some rate-limiting system.

This gives the vague impression of security, but it really seems just
the placing of a few obstacles in the way.

And "auditing" sounds like a euphemism for "pass the problem of
security on elsewhere anyway".

Thom