On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> CREATE SECURITY VIEW, anyone?
That may be the best approach, but I think it needs more than one line
of exposition. The approach I proposed was to test whether the user
has privileges to execute the underlying query directly without going
through the view. If so, we needn't be concerned. If not, then we
start thinking about which functions/operators we trust.
The only disadvantage to that approach that I see is that it
introduces some extra permission-checking overhead. If having an
explicit notion of which views are intended to be security views
enables us to reduce or eliminate that overhead, it may be worth
doing. But I'm not sure that it does. A blanket rule that says
"don't push untrusted quals into security views" is not going to be
too satisfactory - we probably want to do that only when the view is
queried by an untrusted user - the superuser, or someone else with
adequate permissions, will presumably still want his quals to get
pushed down.
Perhaps there is some value to having a knob that goes the opposite
directions and essentially says "I don't really care whether this view
is leaky from a security perspective". But presumably we don't want
to deliver that behavior by default and require the user to ask for a
SECURITY VIEW to get something else - if anything, we'd want CREATE
VIEW to create the normal (secure) version and add CREATE LEAKY VIEW
to do the other thing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company