On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
