Re: Using views for row-level access control is leaky

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Marc Munro <marc(at)bloodnok(dot)com>, Rod Taylor <rod(dot)taylor(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using views for row-level access control is leaky
Date: 2009-10-23 14:24:23
Message-ID: 20091023142423.GF28926@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 23, 2009 at 10:04:29AM -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei wrote:
> >> Sorry, what is happen if function is marked as "plan security"?
>
> > I was suggesting an intelligent default by which we could
> > determine function marking implicitly, if it was not explicitly
> > stated on the CREATE FUNCTION.
>
> The thought that's been in the back of my mind is that you could
> solve 99% of the performance problem if you trusted all builtin
> functions and nothing else. This avoids the question of who gets to
> mark functions as trustable.

Great idea!

One of the things the security community has learned is that the only
way it's even possible to get an information leak rate of zero is to
have a system which does nothing at all. It's a fact we need to bear
in mind when addressing this or any other issue of access control.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-10-23 14:32:31 Re: plpgsql EXECUTE will not set FOUND
Previous Message Robert Haas 2009-10-23 14:16:23 Re: plpgsql EXECUTE will not set FOUND