Re: [RFC] A tackle to the leaky VIEWs for RLS

2010/6/1 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> Eh, if that's the consensus, it doesn't bother me that much, but it
>> doesn't really answer the question, either: supposing we add an
>> explicit concept of a security view, what should its semantics be?
>
> How about a GUC option to provide the default, like default_with_oids?

Bad idea. We already have enough problems with GUCs that can create
security problems if they're unexpectedly set to the wrong value. We
don't need any more. Anyhow, that's trivia. The real thing we need
to decide here is to design the security mechanism. We can change the
syntax to whatever we want very easily.

Here's another thought. If we're leaning toward explicit syntax to
designate security views (and I do mean IF, since only one person has
signed on to that, even if it is Tom Lane!), then maybe we should
think about ripping out the logic that causes regular views to be
evaluated using the credentials of the view owner rather than the
person selecting from it. A security view would still use that logic,
plus whatever additional stuff we come up with to prevent leakage.
Perhaps this would be viewed as a nasty backward compatibility break,
but the upside is that we'd then be being absolutely clear that a
non-security view isn't and can never be trusted to be a security
barrier. Right now we're shipping something that purports to act as a
barrier but really doesn't.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company