Re: [PATCH] Fix leaky VIEWs for RLS

(2010/06/08 10:17), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> Perhaps, pg_proc takes a new flag to represent it.
>
> Without an actual well-formed approach for dealing with this which
> requires it, it's far too soon to be asking for changes in the catalog.
> Please stop suggesting individual maybe-this-would-help changes. We
> need an actual solution which addresses all, or at least most, of the
> concerns described, followed by a patch which implements the mechanics
> of the solution. If the solution calls for an additional pg_proc field,
> then the patch should include it.
>
OK, it was too implementation-specific.

Please return to the categorization with 3-level that I mentioned at
the previous message.

I guess nobody opposes to disable pushing down on functions categorized
to high-threat, such as lowrite() and so on.
It actually can move given arguments to other tables, files, ...

And, I guess nobody wants to tackle an issue categorized to low-threat,
such as EXPLAIN, PK/FK constraints and so on.
It can imply existence of invisible objects, but no leaks of actual value.

Our headache is on functions categorized to middle-threat. It enables to
leak the given arguments using error messages. Here are several ideas,
but they have good and bad points.

At first, it is necessary whether we should fix up the threat in this
level, or not. It seems to me majority of the -hackers want to fix both
of high and middle level.

If we should fix up the issue, I think we have only two options semantically.

(A) It prevents leaky functions to be pushed down, so no invisible
information will be provided. But it makes performance regression.

(B) It prevents leaky functions to raise an error, although we allow
it to be pushed down. But is needs large scale of code changes.

Of course, it has trade-off. As TCSEC mentioned, we are facing with the
large potential cost of reducing the bandwidths of such covert channel

> Not sure if this would translate well, but asking for new flags to be
> added to pg_proc right now is putting the cart before the horse. We
> don't even know which functions we might mark as trusted or not yet, nor
> is it even clear that adding such a flag would actually help. Adding a
> flag to pg_proc is certainly nothing like a solution to this problem by
> itself.
>
For built-in functions, the code should be reviewed to ensure it does not
expose the given argument using error messages.
Then, we can mark it as trusted.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>