Re: Review of Row Level Security - Mailing list pgsql-hackers

From David Fetter
Subject Re: Review of Row Level Security
Date
Msg-id 20130102174439.GD21748@fetter.org
Whole thread Raw
In response to Re: Review of Row Level Security  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Wed, Jan 02, 2013 at 05:31:42PM +0000, Simon Riggs wrote:
> On 2 January 2013 17:19, David Fetter <david@fetter.org> wrote:
> 
> > Would COPY be covered separately?  How about TRUNCATE?
> 
> COPY == INSERT

Makes sense.  The reason I mentioned it is that COPY is supposed to be
a very fast bulk loading process, which implies a couple of things:

1.  In the RLS (really should be RLAC, but let's not go there now)
case, COPY makes it pretty simple to probe hugely many things at once
for existence unless there's some kind of COPY pre-processor that
throws away non-matching rows.  Fortunately there's work being done to
that end.

2.  COPY, being intended to be very, very fast, should probably get
some kind of notation, at least in the docs, about how it will slow
down in the RLS case.

> TRUNCATE isn't covered at all since it doesn't look at rows. It has a
> separate privilege that can be granted to those that need it.

OK

> > Also, is there any way to apply this to the catalog, or would that
> > be too large a restructuring, given how catalog access actually
> > works?
> 
> Doubt it.

Somewhat related issue:  Is there a worked example of setting up
PostgreSQL to a "default deny" access policy as far as is possible
today?  This touches a lot of things, among them reading the catalog.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Review of Row Level Security
Next
From: Greg Stark
Date:
Subject: Re: pg_basebackup from cascading standby after timeline switch