On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@gmail.com> writes: >>>> 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. >>> >>> Ummm ... that makes semantics dependent on the permissions available at >>> plan time, whereas what should matter is the permissions that exist at >>> execution time. Maybe that's all right for this context but it doesn't >>> seem tremendously desirable. >> >> Ugh. I hope there's a way around that problem because AFAICS the >> alternative is a world of hurt. If we're not allowed to take the >> security context into account during planning, then we're going to >> have to make worst-case assumptions, which sounds really unpleasant. >> >>>> 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. >>> >>> -1 on that. We will get far more pushback from people whose application >>> performance suddenly went to hell than we will ever get approval from >>> people who actually need the feature. Considering that we've survived >>> this long with leaky views, that should definitely remain the default >>> behavior. >> >> 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? > > have you ruled out: 'create function'? :-)
You lost me... -- 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