Re: [PATCH] Fix leaky VIEWs for RLS

(2010/06/07 12:06), Stephen Frost wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> Another idea I had was... would it be safe to trust functions defined
>> by the same user who owns the view? If he's granted access to the
>> view and the function to some other user, presumably he doesn't mind
>> them being used together? Or is that too optimistic?
>
> This was more-or-less what I'd been kind of kicking around in my head.
> Forget about functions that are defined in the view itself. Any other
> functions, etc, which are attached to the view by the calling user would
> be suspect, etc. Perhaps with the exception of some built-ins that
> we've marked as "safe" in some way.
>
> My first thought was to track the "run this as X" information on every
> RTE (more-or-less, relations, function calls, etc) and then at least be
> able to, hopefully, *detect* situations that might be a problem- eg:
> running a function which has "run as Q" against a relation that was
> accessed as "run as R" when a filter "run as R" happens later. This is
> all far too hand-wavey, I'm sure, but at least if we could detect it
> then we might be able to find a way to deal with it.
>
It is a similar idea to what I tried to implement at the conceptual
patch. It checks privileges of calling user on the underlaying tables
to be referenced using views. If violated, it prevents to push down
the user given FuncExpr into join loops of views. Otherwise, it does
not prevent anything, because the user originally has privileges to
reference them.
Are you suggesting the idea (with adjustments such as "safe" functions)?

> Also, perhaps I'm not being paranoid enough, but all this concern over
> error cases really doesn't really worry me that much. The amount of
> data one could acquire that way is pretty limited. It'd be great if we
> could deal with that case too, but maybe we could worry about the bigger
> issue (at least, as I see it) first.
>
As I also mentioned at previous message. It seems to me a good
point to focus on bandwidth of the covert channel.

The error message indeed can deliver information to be invisible,
but I don't think its priority is higher than functions that can
be abused to direct data flow channel, such as lowrite().

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