Re: Review of Row Level Security

On Wed, Jan 02, 2013 at 05:31:42PM +0000, Simon Riggs wrote:
> On 2 January 2013 17:19, David Fetter <david(at)fetter(dot)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(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
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

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