Skip site navigation (1) Skip section navigation (2)

Re: Review of Row Level Security

From: David Fetter <david(at)fetter(dot)org>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Robert Haas <robertmhaas(at)gmail(dot)com>,Kevin Grittner <kgrittn(at)mail(dot)com>
Subject: Re: Review of Row Level Security
Date: 2013-01-02 17:44:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?

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.


> > 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.

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

Remember to vote!
Consider donating to Postgres:

In response to

pgsql-hackers by date

Next:From: Greg StarkDate: 2013-01-02 18:04:39
Subject: Re: pg_basebackup from cascading standby after timeline switch
Previous:From: Simon RiggsDate: 2013-01-02 17:31:42
Subject: Re: Review of Row Level Security

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group